Ja izstrādājat saskarnes React vai citos ietvaros frontendAgrāk vai vēlāk jūs sapratīsiet, ka paļauties tikai uz to, ka "tas darbojas manā datorā", ir spēlēšanās ar uguni. Nelielas komponentes izmaiņas, ātra refaktorēšana vai atjaunināta atkarība var salauzt lietojumprogrammas daļas, pat nepamanot... Ja vien jums nav laba vienību testēšanas sistēma, kas iestatīta ar Jest.
Mūsdienu JavaScript ekosistēmai ir automatizēta testēšana savā DNS. Tādi rīki kā Jest viņi taisa Rakstīt komponentu testusFunkciju un āķu lietošanai ikdienas darbā vajadzētu būt viegli paveicamai, pat ja neesat testēšanas fanātiķis. Galvenais ir ērti iekārtoties, izprast testu rakstīšanu un zināt, kā interpretēt rezultātus un to aptvērumu, lai noteiktu koda daļas, kas netiek testētas.
Kāpēc front-end projektos tiek veikta vienības testēšana?
Vienības testi ir mazi testi, kas apstiprina konkrētas jūsu koda daļas (funkcijas, komponenti, āķi, utilītas…). Priekšējās izstrādes procesā tie ir īpaši noderīgi, jo saskarne bieži mainās, pastāv stāvokļa loģika, lietotāju notikumi, asinhroni izsaukumi utt. Bez drošības tīkla katras izmaiņas ir riskanta rīcība.
Starp acīmredzamākajām vienības testēšanas priekšrocībām ir agrīna kļūdu atklāšanaTā vietā, lai atklātu kļūdas, kad lietotājs jau ir ražošanas vidē, jūs tās atklājat, tiklīdz saglabājat izmaiņas un palaižat testēšanas komplektu, kas palīdz labāk izprast kļūdu dzīves ciklsTas ietaupa komandai laiku, naudu un daudz galvassāpju.
Vēl viens ļoti spēcīgs arguments ir tas, ka Testi galu galā darbojas kā dzīva dokumentācija.Redzot, kā ir uzrakstīts komponentes vai funkcijas tests, kļūst skaidrs, kā tas ir paredzēts izmantot, kādus ievades datus tas pieņem un kādus rezultātus tam vajadzētu atgriezt. Lielos projektos tas ir nenovērtējami jauniem komandas locekļiem.
JavaScript un React kontekstā Testu rakstīšana arī palīdz labāk modularizēt kodu.Lai varētu testēt daļu atsevišķi, tai jābūt labi izolētai, ar skaidrām atkarībām un definētām atbildībām, kas vidējā termiņā un ilgtermiņā nozīmē vieglāk uzturējamu front-end sistēmu.
Kas ir Jest un kāpēc to tik daudz izmanto front-end izstrādē?
Jest ir JavaScript testēšanas ietvars, ko sākotnēji izstrādāja Facebook., kas izstrādāts, lai lieliski darbotos ar React, bet ir pilnībā piemērots jebkuram klienta vai servera puses JavaScript vai TypeScript projektam.
Viens no tā lielākajiem aktīviem ir "nulles konfigurācijas" filozofijaDaudzos projektos pietiek ar vienkāršu tā instalēšanu un skripta pievienošanu failam package.json, lai sāktu testus, neiedziļinoties sarežģītos konfigurācijas failos. Tas padara to īpaši pievilcīgu front-end vidēs, kur jau tiek izmantoti daudzi rīki.
Jest integrējas kā standarta komplektācija Galvenās funkcijas front-end projektiem: ātra testu izpilde, vērošanas režīms, kas atkārtoti palaiž testus, konstatējot izmaiņas, ļoti ērts asinhronā koda atbalsts, imitācijas un spiegu risinājumi atkarību simulēšanai, kā arī koda pārklājuma pārskatu ģenerēšana, neizmantojot papildu ārējos rīkus.
Priekšējās gala projektiem ar React Jest gandrīz vienmēr tiek apvienots ar React testēšanas bibliotēkaŠī bibliotēka atvieglo komponentu testēšanu, izmantojot to uzvedību un renderēšanu, nevis pārlieku piesaistot to iekšējai ieviešanai. Ar abiem rīkiem jūs varat apmierināt praktiski visas savas ierastās saskarnes testēšanas vajadzības.
Jest un React testēšanas bibliotēkas instalēšana front-end projektā
Pirmais solis, lai sāktu darbu ar Jest, ir tā pievienošana kā izstrādes atkarība. jūsu projektā. Ja izmantojat npm, tipiskā komanda būtu šāda:
npm instalēt --save-dev joks
Ja vēlaties strādāt ar dzijuTo var instalēt ar:
dzija pievienot --dev jest
React balstītos projektos ir ļoti bieži instalēt arī React testēšanas bibliotēku., kas sastāv no vairākām pakotnēm: bāzes @testing-library/react komponentiem, @testing-library/jest-dom papildu saskaņotājiem DOM un bieži vien @testing-library/user-event, lai simulētu sarežģītas lietotāju mijiedarbības.
Tipiska React iestatīšana varētu izskatīties apmēram šādi:
npm instalēšana – saglabāt-dev @testēšanas-bibliotēka/reaģēt @testēšanas-bibliotēka/jest-dom @testēšanas-bibliotēka/lietotāja-events
Kad šīs atkarības ir ieviestas, jūsu vide ir gatava rakstīt uz komponentiem orientētus vienības testus., notikumi un rezultāti, kas ir redzami lietotājam, vienmēr paļaujoties uz Jest kā galveno testu izpildes dzinēju.
Jest pamata konfigurācija failā package.json
Kad Jest ir instalēts, jums jāpaziņo projektam, kā tiks palaisti testi.Parasti prakse ir pievienot skriptu failam package.json, lai no termināļa iegūtu vienkāršu komandu.
Minimāls konfigurācijas piemērs varētu būt:
{ «skripti»: { «tests»: «jest» } }
Ar šo skriptu jūs varat palaist visus projekta testus, vienkārši palaižot:
npm tests
vai, ja izmantojat dziju, ar:
dzijas tests
Jest automātiski atpazīst testa failus, pamatojoties uz to nosaukumuPēc noklusējuma tas meklēs failus ar sufiksiem .test.js vai .spec.js jūsu mapju kokā, tāpēc parasti jums nav manuāli jānorāda ceļi, ja vien ievērojat šīs konvencijas.
Faila konvencija: .test.js paplašinājums un testa struktūra
Lai Jest varētu atpazīt jūsu testus bez papildu konfigurācijas, Ir ļoti ieteicams izmantot paplašinājumu .test.js. (vai .test.ts, ja strādājat ar TypeScript). Piemēram, ja jums ir Button.jsx komponents, ļoti bieži tā testa nosaukums būtu Button.test.js tajā pašā direktorijā vai atsevišķā testu mapē.
Šai konvencijai ir divas nepārprotamas priekšrocības:
- No vienas puses, Jest automātiski atrod izpildāmos failus.
- No otras puses, ikviens, kas ir jauns projektā, uzreiz zina, kuri faili satur ražošanas kodu un kuri satur testus.
Testus definē testa funkcija vai tās aizstājvārds itkur pirmais arguments ir pārbaudāmā objekta teksta apraksts, bet otrais ir funkcija, kas izpilda testa loģiku. Šīs funkcijas ietvaros apgalvojumi tiek izmantoti, izmantojot `expect` un tā dažādos atbilstības meklētājus.
React komponentos struktūra ir līdzīgaTikai tīras funkcijas testēšanas vietā komponentu renderējat ar React testēšanas bibliotēku, meklējat elementus ekrānā (pēc teksta, lomas, etiķetēm utt.) un, simulējot lietotāja mijiedarbību, pārbaudāt, vai tie tiek parādīti vai reaģē, kā paredzēts.
Uzrakstiet savu pirmo vienības testu, izmantojot Jest
Lai visu to nolaistu uz zemes, Iedomājieties vienkāršu funkciju, kas saskaita divas vērtībasFailā ar nosaukumu sum.js definējiet funkciju sum(a, b) { return a + b; } un eksportējiet to. Pēc tam failā sum.test.js importējiet šo funkciju un definējiet testu ar skaidru aprakstu par to, kam jānotiek.
Testa struktūra ir ierobežota ar funkcijas izpildi un rezultāta validāciju.Jūs izsaucat funkciju sum(1, 2) un izmantojat funkciju expect, lai norādītu, ka vērtībai jābūt tieši 3. Ja funkcija pārstāj atgriezt šo rezultātu (kļūdas vai neparedzētas modifikācijas dēļ), Jest atzīmēs testu kā neveiksmīgu.
Šāda veida tests, lai cik vienkāršs tas nešķistu, ir vienības testēšanas pamats.Katrai funkcijai vai loģiskajai vienībai ir viens vai vairāki testi, kas apraksta, kas tai būtu jādara dažādos scenārijos, lai jebkura novirze no paredzētās uzvedības būtu nekavējoties pamanāma, vienkārši palaižot testu komplektu.
Priekšējās daļas komponentos pieeja ir tikpat vienkāršaJūs renderējat komponentu, pārbaudāt, kas tiek parādīts, simulējat notikumus, piemēram, klikšķus vai rakstīšanu ievades datos, un pārbaudāt, vai iegūtais stāvoklis un DOM atbilst lietojumprogrammas funkcionālā dizaina definīcijai.
Projektam augot, jūs pievienojot vairāk testu, lai aptvertu robežgadījumusnetipiskus ierakstus, kļūdas un mazāk acīmredzamas situācijas, tādējādi pastiprinot lietojumprogrammas uzticamību un novēršot regresijas, ieviešot jaunas funkcijas.
Jest Matchers: dažādi rezultātu pārbaudes veidi
Apgalvojumu būtība darbā "Jest" ir paredzamā funkcijakas ir savienots ķēdē ar dažādiem saskaņotājiem, lai norādītu saņemtās vērtības prasības. Atkarībā no tā, ko testējat, vēlēsities izmantot vienu vai otru saskaņotāju. Šie ir vispraktiskākie saskaņotāji:
- būt. Tas pārbauda stingru vienādību, kas JavaScript valodā nozīmē vienādu vērtību un vienādu tipu, kas ir ļoti noderīgi skaitļiem, virknēm vai Būla izteiksmēm, kur sagaidāma precīza atbilstība. Ja sagaidāms 3, tad nev vēlaties, lai tiktu iegūts "3".
- vienādsNoderīgi, strādājot ar objektiem vai masīviem. Šis salīdzinātājs salīdzina objektu struktūru un saturu, lai jūs varētu pārbaudīt, vai funkcija atgriež objektu ar pareizajām īpašībām un vērtībām, pat ja iekšējā atsauce nav tāda pati.
- ne. Ja kādā brīdī ir jāpārliecinās, ka kaut kas NENOTIKS, var izmantot noliegumu `not`. Piemēram, `expect(value).not.toBe(0)` skaidri norāda, ka skaitlim nevajadzētu būt nullei, vai `expect(array).not.toEqual([])` norāda, ka nav jāgaida tukšs masīvs.
Papildus šiem pamatprincipiem Jest piedāvā daudz ko citu citi savedēji: lai pārbaudītu, vai funkcija met kļūdu, vai masīvs satur noteiktu elementu, vai virkne atbilst regulārajai izteiksmei vai, izmantojot jest-dom React gadījumā, vai DOM elements ir redzams, atspējots, vai tam ir noteikts teksts utt.
Asinhronā testēšana Jest valodā: solījumi, asinhronā/gaidīšanas un atzvanīšanas
Mūsdienu front-end ir pilns ar asinhronas darbībasHTTP pieprasījumi, taimeri, lietotāju mijiedarbība, kas aktivizē stāvokļa atjauninājumus utt. Tāpēc Jest integrē vairākus veidus, kā ērti strādāt ar asinhroniem testiem.
Tīrākais un visizplatītākais veids, kā pārbaudīt asinhrono loģiku, ir izmantot asinhrono/aizgaidītJūs deklarējat savu testa funkciju kā asinhronu, gaidāt, kamēr atrisinās pārbaudāmais solījums, un pēc tam veicat ierastos apgalvojumus ar expect uz saņemto rezultātu.
Piemēram, jums varētu būt fetchData funkcija, kas atgriež solījumu, un rakstīt asinhronu testu, kas izsauc fetchData, gaida, kamēr tā tiek atrisināta, un pārbauda, vai atgrieztie dati atbilst gaidītajam, neatkarīgi no tā, vai tas ir konkrēts teksts vai objekts ar noteiktu struktūru.
Jest arī tieši atbalsta solījumus bez asinhronizācijas/aizraušanāsAtgriež pašu solījumu no testa, lai ietvars zinātu, kad darbība ir pabeigta. Turklāt vecākos vai ļoti specifiskos gadījumos tas ļauj izmantot atzvanīšanas pieprasījumus ar parametru `done`, lai norādītu uz testa beigām.
React testēšanas bibliotēkas jomā Asinhronie testi bieži apvieno gaidīšanas funkciju ar findBy vai waitFor, kas ļauj gaidīt, kamēr DOM atjaunināsies pēc pieprasījuma vai stāvokļa maiņas, pirms tiek veikti attiecīgie apgalvojumi.
Izsmiekls Jest valodā: moduļu, funkciju un atkarību simulācija
Vienības testēšanas pamatprincips ir Izolēt testējamo ierīciTas nozīmē, ka, ja funkcija vai komponents ir atkarīgs no ārējiem pakalpojumiem (API, trešo pušu bibliotēkām, ietilpīgiem moduļiem utt.), testa laikā šī uzvedība ir jāsimulē, nevis jāizpilda.
Jests veicina šo izolāciju ar izsmieklu palīdzībuAr jest.fn var izveidot imitētas funkcijas, kas reģistrē, cik reižu tās tiek izsauktas, ar kādiem argumentiem vai kādu vērtību tām vajadzētu atgriezt. Tas ir ļoti noderīgi iekšējo mijiedarbību testēšanai, nepieskaroties šo pakalpojumu faktiskajam kodam.
Kad nepieciešams spert soli tālāk, jest.mock ļauj aizstāt veselus moduļusVarat norādīt, ka, importējot konkrētu failu, Jest jāizmanto fiktīva ieviešana, kas atgriež kontrolētas vērtības, piemēram, izvairoties no reālu HTTP pieprasījumu sūtīšanas katru reizi, kad tiek palaists testu komplekts.
React komponentos bieži tiek izmantotas imitācijas, lai simulētu pielāgotus āķus., datu pakalpojumus vai moduļus, kas pārvalda lokālo krātuvi, analītiku utt., koncentrējoties uz komponenta darbību, nevis uz tā ārējo atkarību darbību.
Pareizi lietots, Izsmiešana ievērojami paātrina testa izpildi. un ļauj viegli reproducēt kļūdu scenārijus, dīvainas servera atbildes vai netipiskus stāvokļus, kurus būtu grūti sasniegt, mijiedarbojoties ar reāliem pakalpojumiem.
Testu organizēšana un grupēšana, izmantojot blokus, apraksta
Testēšanas komplektam augot, jums ir nepieciešams uzturēt minimālo pasūtījumu Lai neapmaldītos starp simtiem testu, kas izkaisīti vairākos failos, Jest piedāvā blokus kā dabisku veidu, kā grupēt saistītus testus.
Ar aprakstu jūs varat pievienot vairākus testus vienā un tajā pašā kontekstāPiemēram, “aritmētiskās darbības” vai “galvenes komponentu uzvedība”. Bloka ietvaros katrs tests apraksta konkrētu gadījumu, bet kopa lasāma kā sava veida sakarīgs stāsts par šo koda daļu.
Šī organizācija palīdz gan lasīšanas, gan atkļūdošanas ziņā.Kad kaut kas noiet greizi, ir vieglāk atrast testa grupu un saprast, kuru sistēmas daļu tas ietekmē, bez nepieciešamības skenēt visu projektu.
Turklāt, apraksta, ļoti labi sader ar Jest dzīves cikla āķiem, piemēram, beforeEach vai afterEach, kas ļauj sagatavot datus vai notīrīt koplietotos stāvokļus visiem testiem vienā blokā, izvairoties no inicializācijas loģikas dublēšanas katrā atsevišķā testā.
Sarežģītos front-end projektos ir ierasts, ka katram komponentam ir apraksts., ja nepieciešams, sadalīts iekšējos aprakstos dažādiem režīmiem, rekvizītiem vai mijiedarbības plūsmām, kas testa failu pārvērš par diezgan skaidru visu, kas tiek sagaidīts no šī komponenta, karti.
NPM testēšanas un izpildes disciplīnas izmantošana darbplūsmā
Kad pamata konfigurācija ir pabeigta, Npm testa komanda kļūst par jūsu ikdienas sabiedrotoTās palaišanai pirms izmaiņu augšupielādes vajadzētu būt gandrīz automātiskai, piemēram, faila saglabāšanai vai lintera palaišanai.
Daudzas komandas pieņem nerakstītu noteikumu, ka nedrīkst pildīt savus pienākumus, ja testi neiztur kritiku.Šī prakse novērš projekta galvenās filiāles darbības pārtraukumus un saglabā garantētu minimālo kvalitāti katrā apvienošanas vai vilkšanas pieprasījumā, kas tiek integrēts repozitorijā.
Jest piedāvā arī ļoti noderīgs interaktīvs režīms izstrādes stadijāPalaižot npm testu vērošanas režīmā, ietvars atkārtoti palaiž tikai tos testus, kas saistīti ar jūsu modificētajiem failiem, kas ievērojami paātrina testēšanas un labošanas ciklu, kamēr jūs izstrādājat jaunas funkcijas vai labojat kļūdas.
Jest integrēšana nepārtrauktas integrācijas (CI) sistēmā kā GitHub darbības pabeigt apliKatru reizi, kad kāds augšupielādē kodu attālajā repozitorijā, CI serveris veic npm testu un bloķē integrāciju, ja komplekts neizdodas, novēršot kļūdu iekļūšanu koplietotajās vidēs.
Koda pārklājums: faktiskā testēšanas apjoma mērīšana
Ar dažiem rakstiskiem testiem vien nepietiek. Interesanti arī uzzināt, cik lielā mērā viņi aptver kodu.Šim nolūkam Jest integrē pārklājuma pārskatu veidošanu, kas norāda, kuras līnijas, funkcijas un atzari ir izpildīti testēšanas laikā.
Šo pārskatu ģenerēšana ir tikpat vienkārša kā karodziņa --coverage pievienošana komandai test.Piemēram, varat konfigurēt package.json skriptu kā "test": "jest --coverage" vai palaist npm test --coverage, ja vēlaties detalizētu pārskatu.
Rezultātā ietilpst pārklājuma procenti katrā failā un globālā līmenīJūs redzēsiet, kuriem failiem ir labs pārklājums un kuriem testēšanas laikā gandrīz netiek pieskarts, kas palīdzēs jums izlemt, kur ir vērts ieguldīt papildu pūles, lai rakstītu vairāk testu.
Protams, ir vērts atcerēties, ka 100% pārklājums negarantē kļūdu neesamībuIr iespējams palaist visas koda rindiņas ar neprasīgiem testiem, tāpēc apgalvojumu kvalitāte ir tikpat svarīga vai pat svarīgāka par pašu skaitli.
Izmantojiet pārklājumu kā aptuvenu indikatoru, apvienojumā ar koda pārskatiem un veselo saprātuTas ir labs veids, kā saglabāt līdzsvaru starp testēšanas piepūli un reāliem ieguvumiem projekta stabilitātei.
Ar visu redzēto, Jest un tādu rīku kā React Testing Library izmantošana front-end projektos Tas kļūst par diezgan loģisku lēmumuTas ļauj pārbaudīt, vai katrs komponents un funkcija dara to, kas tam paredzēts, viegli veikt testus ar npm testu, uzraudzīt pārklājumu ar –coverage un uzturēt stabilu koda bāzi, kur ir daudz drošāk attīstīt produktu, nebaidoties sabojāt jau darbojošos.
