Ето ни отново и както обещах в моята последна история, ще споделя моя опит за това как да прилагам Unit Tests и TDD в React приложение. Следвайте, тъй като тази история няма да бъде забравена.
Ветровете на промяната…
Това е история за променящите се времена и модернизацията, в земя на пепел, огън, война… и пристрастеност към онлайн пазаруването.
Нашата история започва с нашия Тъмен магьосник Зауром, чийто бизнес с тъмни оръжия е в упадък поради липсата на ковашки работилници в Нордор. Орките са станали много мързеливи в наши дни и предпочитат да пазаруват онлайн, за да могат да персонализират своите брони и оръжия за битка и да ги доставят на вратата им.
Майстор Зауром призовава своя най-лоялен и опитен програмист-магьосник и заплашва... Искам да кажа, че го моли да създаде онлайн магазин за персонализирани артефакти за Warcraft. Първите поръчки са:
- Включете каталог с палци или военните артефакти (мечове, щитове, машини, заклинания, консумативи), показващи също цена в злато, име и кратко описание.
- Покажете общата сума на покупката в малка джаджа до каталога с артефакти.
- Артефактите могат да се добавят в пазарската количка, като щракнете върху изображението или името на артикула в каталога.
Това трябва да са доста лесни задачи — казва тъмният владетел. По този начин магьосникът се връща в стаята си в черната кула, за да започне със задачата си.
Като експерт и мъдър магьосник той вече беше подготвил „стартов проект“ (клонирайте го, за да продължите да следвате), който го измъкна от скучната първоначална настройка.
Тестове за кастинг...
Първото нещо първо. Като експерт-разработчик, ъъъ… магьосник, той знае стойността и важността на Unit Tests, TDD и простотата на Tape, така че започва своя код по следния начин:
Целта на този модулен тест е да се увери, че каталогът изобразява правилното маркиране от предоставения модел на данни.
За това използваме набор от магически инструменти (React, cheerio, React-Dom) и техника, наречена Pure Components, за да улесним нашата задача за проверка.
Магьосникът преглежда старите си книги, за да си спомни защо трябва да следва този път...
„Чистотата и опростеността са тайната на истинската възможност за тестване, надеждност и мащабируемост. Подобно на съставките за Философския камък, само чисти компоненти могат да създадат такъв магически шедьовър. ”
Чистите компоненти са начин за изграждане на React приложения, като всеки повторно използваем компонент е фабрична функция, която връща React елемент въз основа на свойствата (реквизити), предадени му.
Ползите от този стил са значителни! — казва си магьосникът. Липсата на безпокойство за контекста наистина опростява тестването и също така прави задачата за композиране очарователна.
Сега, за да завърши задачите, препоръчани от господаря му, магьосникът смята, че би било добра идея да направи логиката за показване на продукта също компонент. Така че той пише теста за това:
Ако се чудите как по средата на земята използваме JQuery тук, тогава ще ви разочаровам, не сме, ние използваме cheerio.
Cheerio е опростена версия на JQuery API за страната на сървъра, която наистина помага да се направи тестване без главоболието от работа с пълно DOM заглушаване. Благодаря на Eric Elliott за пробата на използване на cheerio за тези сценарии.
Не забравяйте, че чистите компоненти са свободни от контекста и не се интересувайте къде се изобразяват, този подход трябва да работи, стига да уважавате чистотата на компонентите — казва вътрешният глас на магьосника.
Разбърква се...
Тестовете не лъжат:
✓ Catalog should be a list of 3 .product items ✓ Product should have image, name, description and price displayed # tests 5 # pass 5 ✓ ok
Композирането беше лесно. Pure Functional Components доказаха, че са достойни.
Тогава дълбокият ревящ глас на господаря му прозвуча като гръм в стаята на магьосниците - Покажи ми какво имаш. — каза тъмният господар.
Магьосникът се задейства бързо, за да свърже приложението с някои фалшиви данни и да покаже на господаря си какво е постигнал досега...
И записът в index.js...
С това той успя да покаже преглед на каталога с оръжия и да спаси душата си… засега.
Разпалване на нещата
Досега създадената магия е готина, но не харесва Тъмния лорд. Време е нашият магьосник да подправи нещата и да управлява действията в количката.
И разбира се, ето тест за това...
Чистотата и простотата на първо място. Компонентът не носи отговорност за добавянето на избрания артикул в пазарската количка. Неговата задача е да покаже визуализация на абстрактните данни и да предостави на потребителя начин за взаимодействие със системата.
Така че това, което трябва само да тестваме, е дали манипулаторът на събития при кликване изпраща правилното събитие с правилния полезен товар. Благодарение на Sinon и skin-deep това също беше лесна задача за магьосника.
Малък рефактор към продуктовия компонент:
Следва продължение…
Как би свършила тази история? Останете на линия и ще разберете в продължението на тази статия, където свързвам това с функционално реактивно програмиране.
Излитането
Мисля, че Pure Components в React area е чудесно допълнение към тази версия O.14. Както виждате, те имат няколко предимства като:
- Изпитаемост. Това, че сте компонентни функции без състояние, прави тестването очарователно. Няма DOM контекст или състояние на екземпляр, за да се притеснявате. Просто предайте модел и сте готови да тествате.
- Надеждност. Без магически глобали или наследена бъркотия. Всяка зависимост, изисквана от компонента, се инжектира или се вижда нейният произход.
- Скалируемост. Функциите са най-простият израз на компютърна програма. Функциите на чистите компоненти могат лесно да бъдат съставени за създаване на по-сложни решения и пак ще можете да разменяте блокове и да разширявате с много по-голяма увереност.
- Размяна. Този начин на работа с компоненти улеснява превключването от библиотеки за изгледи. Ако не искате повече да използвате React, можете да го промените от която и да е виртуална библиотека (Deku, Hyperscript), която поддържа JSX. Вие не свързвате приложението си с React.
Не забравяйте, че Unit Testing е за проверка на функционалността на индивидуални единици код. Казвам това, защото съм бил свидетел отново и отново на разработчици, които си скубят косите и се отказват от практиката, защото се опитват да тестват неща, които не трябва да бъдат част от теста на единица, губейки ценно време. Говоря за неща като симулиране на кликвания, DOM събития, сървърни събития, пълни библиотеки и т.н.
Тестовете за пълна интеграция или E2E трябва да бъдат делегирани на различен слой инструменти като NightWatch, PhantomCSS (регресия на потребителския интерфейс). „Задайте на кода си основните въпроси“ и се съсредоточете върху предоставянето на функционалност.
Благодаря, че прочетохте до тук. До следващия път.
