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

Наскоро изнесох лекция на семинар за Cypress и как да го използвам за E2E тестване. Cypress е мощен инструмент с интуитивен интерфейс, който позволява на разработчиците да отстраняват грешки в тестовете стъпка по стъпка и да виждат състоянието на потребителския интерфейс, докато инспектират елементи, полезни натоварвания на API и т.н. Един от най-трудните аспекти на E2E тестването е тестването на крайни случаи. В исторически план това означаваше, че или ще имаме нужда от начална база данни с правилните данни, или нашите тестове ще трябва първо да създадат данните, преди да ги локализират в нашия тестов поток. Това увеличи времето, необходимо за провеждане на тестовете, и често допринасяше за нестабилността на нашите тестове. Cypress ни позволява да заглушаваме нашите отговори от сървъра, да чакаме отговори и да достигаме до всеки ръбов случай с относителна лекота.

Можете да видите разговора тук: https://youtu.be/GH9Dvo_BYkk

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

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

Cypress сам по себе си няма вградени инструменти за визуално тестване, но има няколко опции, които го правят лесен за изпълнение. Първата опция е по-ръчен процес, но е безплатна за използване. Тази опция е npm библиотека, наречена cypress-visual-regression, която използва библиотеката PixelMatch за извършване на сравнения на изображения. Тази библиотека е плъгин за кипарис, който улавя базови изображения и след това сравнява текущите изображения в следващите тестове. Ако някое от изображенията се различава, се извежда грешка и разликите могат да бъдат проверени.

Веднъж инсталиран, е необходима известна конфигурация. Първо трябва да създадем файл cypress.json, ако той все още не съществува в нашия проект. Трябва да кажем на cypress къде се намира папката със снимки на екрана по подразбиране и дали искаме да изхвърлим изображения от предишни тестове (без нашата базова линия), когато стартираме нов тест. След като конфигурираме това, трябва да кажем на Cypress за нашия плъгин. Това включва редактиране на файла plugins/index.js, за да се каже на Cypress за приставката и след това на файла с команди, за да се добави нова команда Cypress.

След като конфигурираме нашия плъгин, нашите тестове изглеждат като обикновени тестове на Cypress.

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

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

Cypress ще започне тестовете, ще направи екранни снимки и ще сравни текущата екранна снимка с базовата линия. Ако нещо е различно, тестът ще се провали и ние можем да инспектираме изображенията, за да видим базовата линия, действителната и разликата. Това е ръчен процес, който работи добре локално на машина за разработка, но може да се окаже по-труден, когато се използва сървър за непрекъсната интеграция в облака.

Ако този последен подход ви се стори малко прекалено ръчен и ви остави чувството, че искате да има нещо повече, тогава този раздел е за вас. Страхотно е да имаме безплатни инструменти, които ни помагат да започнем, но в по-големи производствени среди е хубаво да разполагаме с всички предимства.

Percy.io е инструмент за визуално тестване, базиран на облак, който се интегрира добре в Cypress и предоставя разширени функции като работен процес и git hooks. Инсталирането е много лесно с проста инсталация на npm и след това един ред за импортиране, за да го интегрирате във вашите тестове. Добавете вашия токен Percy към вашата среда и Percy ще се погрижи за останалото.

Има няколко междинни стъпки, които включват създаване на акаунт с Percy.io, след което създаване на нов проект. След като създадете проект, ще трябва да копирате вашия PERCY_TOKEN за проекта и да го добавите към екземпляра на командния ред по този начин.

Cypress ще изпълни вашите тестове и навсякъде има „cy.percySnapshot();“ call, Percy ще направи моментна снимка, ще я качи в облака и ще сравни резултатите с базовата линия (ако има такава, в противен случай новото изображение ще стане базова линия). Можете да посочите ширините на екрана за заснемане и Пърси ще свърши цялата работа, за да обедини вашето тестово изпълнение в работен процес за вашето одобрение

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

В допълнение, Percy.io има GitHub куки за интегриране във вашия PR процес, за да гарантира, че визуалните промени са одобрени, преди кодът да бъде обединен към следващия клон. Този процес на одобрение създава солиден процес на качество на кода, когато се комбинира с прегледи на кода, линтинг, тестове на модули, покритие на кода и E2E тестване.

Ако сте готови да пренесете вашата тестова игра на следващото ниво, определено трябва да помислите за визуално тестване с Cypress и Percy.io. Тези два продукта, когато се комбинират заедно, ни дават нов инструмент в нашия колан с инструменти за предотвратяване на произволни промени в потребителския интерфейс, които иначе биха били лесно пропуснати от типичните методи за ръчно валидиране.