Ако разработвате интерфейси в React или други рамки на интерфейсаРано или късно осъзнавате, че да разчитате единствено на „работи на моята машина“ е игра с огъня. Малка промяна в компонент, бързо рефакториране или актуализирана зависимост могат да повреждат части от приложението, без дори да забележите... Освен ако не сте... добра система за модулно тестване, настроена с Jest.
Съвременната JavaScript екосистема има автоматизирано тестване в своето ДНК. Инструменти като има те правят Пишете тестове за компонентИзползването на функции и куки би трябвало да е лесно за управление в ежедневната ви работа, дори и да не сте фанатик на тестването. Ключът е да имате удобна настройка, да разбирате как се пишат тестове и да знаете как да интерпретирате резултатите и покритието, за да идентифицирате области от кода си, които остават непроверени.
Защо се прави модулно тестване във фронтенд проекти?
Единичните тестове са малки тестове, които валидират специфични части от вашия код (функции, компоненти, куки, помощни програми…). В frontend разработката те са особено полезни, защото интерфейсът се променя често, има логика на състоянията, потребителски събития, асинхронни извиквания и т.н. Без предпазна мрежа всяка промяна е хазарт.
Сред най-ясните предимства на модулното тестване са ранно откриване на грешкиВместо да откривате грешки, когато потребителят вече е в производство, вие ги откривате веднага щом запазите промените и стартирате тестовия пакет, което ви помага да разберете по-добре... жизнен цикъл на грешкаТова спестява на екипа време, пари и много главоболия.
Друг много силен момент е, че Тестовете в крайна сметка функционират като жива документация.Виждането на начина, по който е написан тест за даден компонент или функция, показва как се очаква той да се използва, какви входни данни приема и какви резултати трябва да върне. В големи проекти това е безценно за новите членове на екипа.
В контекста на JavaScript и React, Писането на тестове също помага за по-добра модулизация на кодаЗа да можете да тествате даден компонент отделно, е необходимо той да е добре изолиран, с ясни зависимости и дефинирани отговорности, което се превръща в по-лесна за поддръжка фронтенд част в средносрочен и дългосрочен план.
Какво е Jest и защо се използва толкова много във фронтенд разработката?
Jest е рамка за тестване на JavaScript, първоначално разработена от Facebook., проектиран да работи чудесно с React, но е напълно валиден за всеки клиентски или сървърен JavaScript или TypeScript проект.
Едно от големите му предимства е философията на „нулевата конфигурация“В много проекти, простото инсталиране и добавяне на скрипт към файла package.json е достатъчно, за да започнете да изпълнявате тестове, без да се затруднявате със сложни конфигурационни файлове. Това го прави особено привлекателен във фронтенд среди, където много инструменти вече се използват.
Jest се интегрира като стандарт Ключови характеристики за фронтенд проектиБързо изпълнение на тестове, режим на наблюдение, който повторно изпълнява тестове при откриване на промени, много удобна поддръжка за асинхронен код, mocks и spy за симулиране на зависимости и генериране на отчети за покритие на кода, без да се разчита на допълнителни външни инструменти.
За фронтенд проекти с React, Jest почти винаги се комбинира с Библиотека за тестване на ReactТази библиотека улеснява тестването на компоненти чрез тяхното поведение и рендиране, вместо да бъде прекалено обвързана с вътрешната имплементация. С двата инструмента можете да покриете почти всички ваши обичайни нужди за тестване на интерфейси.
Инсталиране на библиотека за тестване на Jest и React във фронтенд проект
Първата стъпка за започване на работа с Jest е да го добавите като зависимост за разработка във вашия проект. Ако използвате npm, типичната команда би била:
npm инсталиране --save-dev шега
Ако предпочитате да работите с преждаМожете да го инсталирате с:
добавяне на прежда --dev шега
В проекти, базирани на React, е много често срещано да се инсталира и библиотеката за тестване на React., който се състои от няколко пакета: базовия @testing-library/react за компоненти, @testing-library/jest-dom за допълнителни съпоставители в DOM и често @testing-library/user-event за симулиране на сложни потребителски взаимодействия.
Типична настройка на React може да изглежда по следния начин:
npm install –save-dev @testing-library/react @testing-library/jest-dom @testing-library/user-event
С тези зависимости, вашата среда е готова да пише компонентно-ориентирани модулни тестове., събития и резултати видими за потребителя, винаги разчитайки на Jest като основен енджин за изпълнение на тестове.
Основна Jest конфигурация в package.json
След като Jest е инсталиран, трябва да кажете на проекта как ще бъдат стартирани тестовете.Обичайната практика е да се добави скрипт към файла package.json, за да се получи проста команда от терминала.
Минимален пример за конфигурация може да бъде:
{ «скриптове»: { «тест»: «шега» } }
С този скрипт можете да стартирате всички тестове на проекта, като просто го стартирате:
npm тест
или, ако използвате прежда, с:
тест за прежда
Jest автоматично открива тестови файлове въз основа на името имПо подразбиране ще търси файлове със суфикси .test.js или .spec.js в дървото на папките ви, така че обикновено не е необходимо да указвате пътища ръчно, стига да спазвате тези конвенции.
Файлова конвенция: разширение .test.js и структура на теста
За да може Jest да разпознава тестовете ви без допълнителна конфигурация, Силно препоръчително е да използвате разширението .test.js (или .test.ts, ако работите с TypeScript). Например, ако имате компонент Button.jsx, много често срещано име за неговия test би било Button.test.js в същата директория или в отделна папка tests.
Тази конвенция има две ясни предимства:
- От една страна, Jest автоматично локализира файловете, които ще бъдат изпълнени.
- От друга страна, всеки, който е нов в проекта, веднага знае кои файлове съдържат производствен код и кои съдържат тестове.
Тестовете са дефинирани от тестовата функция или нейният псевдонимкъдето първият аргумент е текстово описание на това, което проверявате, а вторият е функция, която изпълнява тестовата логика. В тази функция твърденията се използват чрез `expect` и различните му съпоставители.
В React компонентите структурата е подобнаСамо че вместо да тествате чиста функция, вие рендирате компонента с библиотеката за тестване на React, търсите елементи на екрана (по текст, роля, етикети и т.н.) и проверявате дали се показват или реагират както очаквате, когато симулирате потребителски взаимодействия.
Напишете първия си модулен тест с Jest
За да сляза всичко това на земята, Представете си проста функция, която събира две стойностиВъв файл, наречен sum.js, дефинирайте функцията sum(a, b) { return a + b; } и я експортирайте. След това, в sum.test.js, импортирайте тази функция и дефинирайте тест с ясно описание на това, което трябва да се случи.
Тестовото тяло е ограничено до изпълнение на функцията и валидиране на резултата.Извиквате sum(1, 2) и използвате expect, за да посочите, че стойността трябва да бъде точно 3. Ако функцията спре да връща този резултат (поради грешка или непредвидена модификация), Jest ще маркира теста като неуспешен.
Този тип тест, колкото и прост да изглежда, е основата на модулното тестване.Всяка функция или логическа единица има един или повече тестове, които описват какво трябва да прави в различни сценарии, така че всяко отклонение от очакваното поведение е веднага видимо само с изпълнението на тестовия набор.
При frontend компонентите подходът е също толкова лесенВие рендирате компонента, проверявате какво се показва, симулирате събития като кликвания или запис във входни данни и валидирате дали полученото състояние и DOM съответстват на това, което определя функционалния дизайн на приложението.
С разрастването на проекта, вие ще добавяне на още тестове за обхващане на гранични случаинетипични записи, грешки и по-малко очевидни ситуации, като по този начин се засилва надеждността на приложението и се предотвратяват регресии при въвеждане на нови функционалности.
Jest Matchers: различни начини за проверка на резултатите
Сърцевината на твърденията в Jest е функцията за очакванекойто е свързан с различни съпоставители, за да определи изискванията на получената стойност. В зависимост от това какво тествате, ще искате да използвате един или друг. Това са най-практичните съпоставители:
- да бъдеш. Проверява за строго равенство, което в JavaScript означава една и съща стойност и един и същ тип, много полезно за числа, низове или булеви стойности, където очаквате точно съвпадение. Ако очаквате 3, не искате да се получи „3“.
- toEqualПолезно при работа с обекти или масиви. Този съпоставител сравнява структурата и съдържанието на обектите, така че можете да проверите дали дадена функция връща обект с правилните свойства и стойности, дори ако вътрешната препратка не е същата.
- не. Ако в даден момент е необходимо да се уверите, че нещо НЕ се случва, можете да използвате отрицанието `not`. Например, `expect(value).not.toBe(0)` ясно показва, че числото не трябва да е нула, или `expect(array).not.toEqual([])` показва, че не очаквате празен масив.
В допълнение към тези основни функции, Jest предлага много други сватовници: за да се провери дали функция хвърля грешка, дали масив съдържа специфичен елемент, дали низ съответства на регулярен израз или, с jest-dom в случая на React, дали даден DOM елемент е видим, деактивиран, има определен текст и т.н.
Асинхронно тестване в Jest: promises, async/await и callbacks
Съвременният фронтенд е пълен с асинхронни операцииHTTP заявки, таймери, потребителски взаимодействия, които задействат актуализации на състоянието и т.н. Ето защо Jest интегрира няколко начина за комфортна работа с асинхронни тестове.
Най-чистият и най-разпространен начин за тестване на асинхронна логика е използвайте асинхронно/изчакващоДекларирате тестовата си функция като асинхронна, изчаквате promise-то, което проверявате, да се разреши и след това правите обичайните твърдения с expect върху получения резултат.
Например, можете да имате функция fetchData, която връща обещание (promise), и да напишете асинхронен тест, който извиква fetchData, изчаква нейното разрешаване и проверява дали върнатите данни съответстват на очакванията, независимо дали е специфичен текст или обект с определена структура.
Jest също така директно поддържа обещания без async/awaitВръщане на самото обещание от теста, така че рамката да знае кога операцията е приключила. Освен това, в по-стари или много специфични случаи, това позволява използването на обратни извиквания с параметър `done`, за да се посочи краят на теста.
В областта на библиотеката за тестване на React, Асинхронните тестове често комбинират изчаквания с findBy или waitFor, които позволяват изчакване на актуализацията на DOM след заявка или промяна на състоянието, преди да се направят съответните твърдения.
Симулиране на модули, функции и зависимости в Jest: симулиране
Основен принцип на модулното тестване е изолирайте тестваното устройствоТова означава, че ако дадена функция или компонент зависи от външни услуги (API, библиотеки на трети страни, тежки модули и др.), ще е по-добре да симулирате тези поведения, вместо реално да ги изпълнявате по време на теста.
Jest улеснява тази изолация чрез макетиранеС jest.fn можете да създавате фалшиви функции, които записват колко пъти са извикани, с какви аргументи или каква стойност трябва да върнат. Това е много полезно за тестване на вътрешни взаимодействия, без да се налага да докосвате действителния код на тези услуги.
Когато трябва да направите още една крачка напред, jest.mock ви позволява да замените цели модулиМожете да укажете, че при импортиране на определен файл, Jest трябва да използва фиктивна имплементация, която връща контролирани стойности, като например избягва изпращането на реални HTTP заявки всеки път, когато се изпълнява тестовият пакет.
В React компонентите, mocks-овете често се използват за симулиране на персонализирани hooks-ове., услуги за данни или модули, които управляват локалното съхранение, анализи и др., като тестът е фокусиран върху поведението на компонента, а не върху неговите външни зависимости.
Използва се правилно, Мокингът значително ускорява изпълнението на теста. и ви позволява лесно да възпроизвеждате сценарии за грешки, странни отговори на сървъра или нетипични състояния, които биха били трудни за постигане чрез взаимодействие с реални услуги.
Организирането и групирането на тестове с блокове описва
С нарастването на вашия набор от тестове, ще ви е необходимо поддържайте минимален ред За да избегнете изгубването сред стотици тестове, разпръснати в множество файлове, Jest предлага блокове като естествен начин за групиране на свързани тестове.
С описание можете приложете няколко теста в един и същ контекстНапример, „аритметични операции“ или „Поведение на компонента на заглавката“. В рамките на блока всеки тест описва специфичен случай, но наборът се чете като един вид свързана история за тази част от кода.
Тази организация помага както по отношение на четенето, така и по отношение на отстраняването на грешки.Когато нещо се обърка, е по-лесно да се локализира тестовата група и да се разбере коя част от системата засяга, без да се налага да се сканира целият проект.
Освен това, описва се комбинира много добре с куките за жизнения цикъл на Jest, като например beforeEach или afterEach, което ви позволява да подготвите данни или да изчистите споделените състояния за всички тестове в рамките на един и същ блок, като по този начин се избягва дублирането на логиката на инициализация във всеки отделен тест.
В сложни фронтенд проекти е обичайно да има описание за всеки компонент., подразделени, ако е необходимо, на вътрешни описания за различни режими, свойства или потоци на взаимодействие, което превръща тестовия файл в сравнително ясна карта на всичко, което се очаква от този компонент.
Използване на npm тестване и дисциплина на изпълнение в работния процес
След като основната конфигурация е завършена, Командата npm test става ваш ежедневен съюзникСтартирането му преди качване на промени би трябвало да е почти автоматично действие, като запазване на файла или стартиране на linter.
Много екипи приемат неписаното правило, че не се ангажираш, ако тестовете се провалят.Тази практика предотвратява прекъсването на основния клон на проекта и поддържа гарантирано минимално качество във всяка заявка за сливане или изтегляне, която е интегрирана в хранилището.
Jest също предлага много полезен интерактивен режим в процес на разработкаЧрез изпълнение на npm test в режим на наблюдение, рамката изпълнява повторно само тестовете, свързани с файловете, които променяте, което значително ускорява цикъла на тестване и коригиране, докато разработвате нови функции или отстранявате грешки.
Интегриране на Jest в система за непрекъсната интеграция (CI) като Действия на GitHub завършете кръгаВсеки път, когато някой качи код в отдалеченото хранилище, CI сървърът изпълнява npm тест и блокира интеграцията, ако пакетът се провали, предотвратявайки проникването на грешки в споделени среди.
Покритие на кода: измерване на това колко реално е тествано
Само писмени тестове не са достатъчни. Интересно е също да се знае до каква степен покриват кода.За тази цел Jest интегрира отчитане на покритието, което показва кои редове, функции и разклонения са били изпълнени по време на тестването.
Генерирането на тези отчети е толкова просто, колкото добавянето на флага --coverage към командата test.Например, можете да конфигурирате скрипта package.json като "test": "jest --coverage" или да изпълните npm test --coverage, когато искате подробен отчет.
Резултатът включва проценти на покритие за всеки файл и на глобално нивоЩе видите кои файлове имат добро покритие и кои едва се докосват по време на тестването, което ви помага да решите къде си струва да инвестирате допълнителни усилия в писането на повече тестове.
Разбира се, струва си да се помни, че 100% покритие не гарантира липсата на грешкиВъзможно е да се изпълняват всички редове код с ненатрапчиви тестове, така че качеството на твърденията е също толкова важно, или дори по-важно от самото число.
Използвайте покритието като приблизителен индикатор, комбинирано с прегледи на кода и здрав разумТова е добър начин да се поддържа баланс между усилията за тестване и реалните ползи за стабилността на проекта.
С всичко видяно, Използване на Jest и инструменти като библиотеката за тестване на React във фронтенд проекти Това се превръща в доста логично решениеТова ви позволява да проверите дали всеки компонент и функция изпълнява това, което трябва, лесно да провеждате тестове с npm test, да наблюдавате покритието с --coverage и да поддържате солидна кодова база, където е много по-безопасно да развивате продукта, без страх от нарушаване на това, което вече работи.
