Грунд за Front End автоматизация

Тестването на автоматизацията е специализирана работа, която се извършва от QE инженери, които са запознати с включените рамки. В моя екип тази година имаме амбициозна цел да накараме разработчиците да напишат тези тестове за автоматизация като част от процеса на разработка, като по този начин превърнат тестовото покритие (както единица, така и автоматизация) в показател за качеството на кода.

Като разработчик в един от екипите на FrontEnd в Walmart и нуб в процеса на настройка и разработка на автоматизация, споделям опита си за това как се захванах да настроя кодовата база за автоматизация и да я изпълня. Моят екип работи върху онлайн изживяването на Walmart Returns, нашата адаптивна уеб рамка от предния край използва Electrode рамка с отворен код от Walmart за широкомащабно разработка на предния край и изживяването на мобилното приложение с помощта на React Native. Тази публикация е съсредоточена около рамките, които WalmartLabs използва, и е предназначена предимно за програмист, който се занимава с разработка на тестове за автоматизация.

Първо Рамките

Автоматизацията съществува от известно време в Walmart Labs и имаме страхотен екип, посветен на работата по инструментите („TestArmada“). Така че всъщност не трябваше да ходя далеч, за да разбера кои инструменти трябва да използвам. За тези, които са съвсем нови в света на автоматизацията, е полезно да знаят, че Selenium е най-разпространената рамка за автоматизация на тестове (започнала в ThoughtWorks и по-късно подобрена от Google) и много от инструментите на различни езици са разработени върху Selenium apis на уеб драйвер.

Selenium — неговият сървър, базиран на Java, изпълнява протокола WebDriver (който е базиран на Rest протокол, който получава команди за изпълнение в браузър). Сървърът създава отделни процеси, които стартират браузър с активирано отдалечено отстраняване на грешки, върху който издава команди към браузъра.

Magellan — това е програмата за тестване, която изпълнява тестовете паралелно. Подобен е на KarmaJS по това, че провеждането на тестове е отделна грижа от действителното дефиниране на теста. Magellan работи, като намира файлове или етикети и създава нови работни процеси, които работят върху тези тестове. Всеки файл е нов тестов случай, който ще бъде изпълнен в работния файл. Работната среда е пясъчна кутия за всеки тест. Може да работи с тях в паралелен или сериен режим в зависимост от предоставените настройки.

NightwatchJS — е BDD рамката, която абстрахира Seleniums webdriver apis и предоставя рамка за дефиниране на теста. Той поддържа модел на проектиране, наречен „обектен модел на страница“, чрез който HTML страница или мобилна страница може да бъде абстрахирана като фрагменти от страница с commands, sections elements и pages.

Appium — е еквивалентът на Selenium за тестване на мобилни приложения. Nightwatch използва Appium за взаимодействие с мобилното устройство. Appium прилага спецификациите на уеб драйвера, което го прави съвместим с всеки клиент, който използва API на уеб драйвера.

Shifu — е подигравателна рамка, разработена като плъгин с HapiJS. По същество предоставя лесен начин за откриване и конфигуриране на фалшиви модели за определен URI маршрут. За локално тестване или тестване от край до край, бихте искали да започнете с подигравка на всички услуги надолу по веригата, зависими от webapp. Така че, когато стартирате вашата настройка за автоматизация, вие също така стартирате макет сървър, който ще обработва всичките ви извиквания на API надолу по веригата и ще връща фиктивен отговор. Готиното при Shifu е, че има концепция за сесия, която позволява изпращането на различни отговори за маршрут на сесия. Можете да направите това, като извикате вариант за сесия. Вариантите са различни отговори за един и същ маршрут, маркирани по различен начин. Модулът shifu-magellan-nightwatch npm има интеграция извън кутията с Shifu, така че да може лесно да бъде включен във вашата настройка за автоматизация.

Обектният модел на страницата

Елементи — това са логически контейнери за елементите, които ще заявите на страницата си с помощта на CSS или XPath селектори за заявки

Команди — това са абстракции, които ще действат върху вашите елементи

Страници — страницата е композиция от елементи и команди, всички от които са достъпни за обекта страница.

Актьорите в нашата постановка

Бележка за актьорите

Mocked услугите не са задължителни - можете също така да извършвате тестове за автоматизация на настройка на живо или преди продукция
Всеки тест за автоматизация се изпълнява в своя собствена пясъчна среда, която стартира Webapp в това пространство на процеса.
Цялата настройка може да се изпълнява на една локална машина или може да се разпространява по мрежата. Може да имате тестове, изпълнявани от вашата локална машина, разговаряща с отдалечени селенови сървъри, които зареждат уеб приложения от друг домейн.

Настройване

Така че по същество, ако автоматизирате пълно предно приложение, трябва да можете да заредите страницата, да щракнете върху елементи, да зададете стойности на входове, да щракнете върху бутони, да заявявате стойности на елементи и т.н. От самото начало е добра идея да предоставите data-automation-id или някакъв подобен идентификатор към вашите елементи, за да не се налага да зависи от CSS и идентификатори на елементи. Освен това, когато има динамично генерирани елементи (като решетка или списък), избирането на елементи с помощта на CSS родителска йерархия е почти невъзможно, ако всички елементи в мрежата имат едни и същи атрибути на клас. Под капака Selenium използва document.querySelectorAll за получаване на елементите и отстояване на тях. Ако нямате уникален идентификатор или css селектор, това връща списък, ако има повече от едно съвпадение за заявката. В този случай щракването върху елемента няма да работи и Nightwatch Extra ще даде предупреждение, което изглежда така

21:39:35 [WARN] [Nightwatch Extra] getEl saw selector .new-order-item-select-container but result length was 26, with 26 of those :visible

След като вашите предни страници са готови за автоматизация, можете да започнете, като дефинирате структура на папки за съхраняване на вашите тестове за автоматизация. Ние държим това под project_root/test/automation .

Ето примерна структура на папките, която следвахме — това е само ориентировъчно. Докато страницата намира своите elements и commands — трябва да работи добре.

project_root/test/automation
--conf (for configuration files)
--lib (for pageobject models)
---pages
   ----commands
   ----elements
   ----sections
--mocks (for mocks if applicable)
--scripts (bash/csh scripts for command line)
--tests (where the actual tests are)

Ето npm зависимостите, които са необходими, за да работи това (конфигурирано под optionalDependencies.

"async": "0.9.2",
"chromedriver": "2.35.0",
"config": "1.30.0",
"dpro": "1.2.0",
"event-stream": "3.3.4",
"jsonlint": "1.6.2",
"nightwatch": "0.9.9",
"phantomjs": "^2.1.7",
"phantomjs-prebuilt": "2.1.16",
"ps-tree": "1.1.0",
"selenium-server": "3.9.1",
"testarmada-magellan": "10.1.1",
"testarmada-magellan-admiral-plugin": "^3.0.0",
"testarmada-magellan-local-executor": "2.0.0",
"testarmada-magellan-nightwatch-plugin": "7.0.0",
"testarmada-nightwatch-extra": "5.0.0",
"testarmada-renv": "4.1.0",
"webpack-dev-server": "1.16.2"

Двата най-важни конфигурационни файла са

magellan.json— Описва как трябва да се изпълнява magellan. Magellan предоставя кукички за жизнения цикъл, откъдето можем да добавим код за стартиране, за да стартираме Webapp и mocks, ако е необходимо — това е дефинирано в setup_teardown.

nightwatch.json — Описва как трябва да си взаимодействат тестовете и селенът.

Бележка за Nightwatch.json

src папки — показва директорията, където се намират тестовете
изходни папки — е за отчетите за тестване
custom_commands_path — показва папката, където са командите на обекта на страницата — по избор в зависимост от това дали това е отделено или не
custom_assertions_path — показва пътя за персонализирани твърдения, ако има такива — по избор в зависимост от това дали са персонализирани твърдения
page_object_path — директория, където са обектите на страницата
globals_path — страница, където се намира всеки файл с глобални променливи
конфигурация на селен — конфигурации на селен сървър и драйвери

Тестът!

Тестът е екземпляр на BaseTest, написан във функции в стил BDD.

Тествайте наследството

Можем да добавим допълнителни функции към тестовия обект, като наследим теста и добавим функции към неговия прототип. Това е полезно, за да имате някои общи функции във всички тестове. Освен това тестовият прототип има функциите before , beforeEach , afterEach и after, които могат да бъдат заменени.

Неуспешни тестове за отстраняване на грешки

Ако тестът е неуспешен и не сте сигурни защо, можете да проверите правилността на селектора на CSS заявки, като инсталирате приставката Selenium IDE за Chrome и стартирате теста от там. Всички извиквания на API на WebDriver са асинхронни. Така че проверката на резултата от повикването помага да се провери правилността на теста.

Тестване в голям мащаб с помощта на SauceLabs

Тестването на огромно количество паралелни тестове изисква инфраструктура и ресурси, които локалната работна станция може да не са достатъчни. В Walmart използваме SauceLabs, за да изпълняваме нашите тестове като част от нашия CI CD Pipeline. Това е хоствана платформа, на която можете да провеждате тестове.

В заключение

В WalmartLabs правим автоматизираното тестване първокласно изискване за разработка, при което разработчиците ще добавят тестови случаи за автоматизация за всяка функция, която разработват. Това изисква културна промяна, която сега набира скорост. Надяваме се, че тази публикация щеше да помогне за разбирането на това как основните компоненти работят заедно и да предостави бързо ръководство за първоначално зареждане за автоматизирано тестване.

Грунд за Front End автоматизация