Jos kehität käyttöliittymiä Reactissa tai muissa sovelluskehyksissä käyttöliittymäEnnemmin tai myöhemmin huomaat, että pelkästään "toimii minun koneellani" -ajatteluun luottaminen on tulella leikkimistä. Pieni komponentin muutos, nopea uudelleenjärjestely tai päivitetty riippuvuus voi rikkoa osia sovelluksesta huomaamattasi... Ellet ole... hyvä yksikkötestausjärjestelmä, joka on rakennettu Jestillä.
Nykyaikaisella JavaScript-ekosysteemillä on automaattinen testaus DNA:ssaan. Työkalut, kuten on tee se Kirjoita komponenttien testejäFunktioiden ja koukkujen käytön tulisi olla hallittavissa päivittäisessä työssäsi, vaikka et olisikaan testausfanaatikko. Tärkeintä on mukava asetelma, testien kirjoittamisen ymmärtäminen ja tulosten ja kattavuuden tulkitseminen, jotta voidaan tunnistaa koodisi testaamattomat alueet.
Miksi yksikkötestausta tehdään frontend-projekteissa?
Yksikkötestit ovat pieniä testejä, jotka validoivat tiettyjä osia koodistasi (funktiot, komponentit, koukut, apuohjelmat…). Frontend-kehityksessä ne ovat erityisen hyödyllisiä, koska käyttöliittymä muuttuu usein, siinä on tilalogiikkaa, käyttäjätapahtumia, asynkronisia kutsuja jne. Ilman turvaverkkoa jokainen muutos on uhkapeliä.
Yksikkötestauksen selkeimpiä etuja ovat mm. varhainen virheiden havaitseminenSen sijaan, että löytäisit virheitä vasta, kun käyttäjä on jo tuotannossa, havaitset ne heti, kun tallennat muutokset ja suoritat testipaketin, mikä auttaa sinua ymmärtämään paremmin vikojen elinkaariTämä säästää tiimiltä aikaa, rahaa ja paljon päänvaivaa.
Toinen erittäin voimakas pointti on se, että Testit toimivat lopulta elävänä dokumentaationa.Komponentin tai funktion testin kirjoitusasun näkeminen tekee selväksi, miten sitä odotetaan käytettävän, mitä syötteitä se hyväksyy ja mitä tuloksia sen tulisi palauttaa. Suurissa projekteissa tämä on korvaamatonta uusille tiimin jäsenille.
JavaScriptin ja Reactin yhteydessä Testien kirjoittaminen auttaa myös koodin modularisoinnissa.Jotta jotakin osaa voidaan testata erikseen, sen on oltava hyvin eristetty, ja sen riippuvuuksien ja vastuiden on oltava selkeät. Tämä tarkoittaa keskipitkällä ja pitkällä aikavälillä helpommin ylläpidettävää käyttöliittymää.
Mikä on Jest ja miksi sitä käytetään niin paljon frontend-kehityksessä?
Jest on alun perin Facebookin kehittämä JavaScript-testausjärjestelmä., joka on suunniteltu toimimaan loistavasti Reactin kanssa, mutta sopii täydellisesti mihin tahansa asiakaspuolen tai palvelinpuolen JavaScript- tai TypeScript-projektiin.
Yksi sen suurimmista vahvuuksista on "nollakonfiguraation" filosofiaMonissa projekteissa pelkkä sen asentaminen ja komentosarjan lisääminen package.json-tiedostoon riittää testien aloittamiseen ilman, että tarvitsee sotkeutua monimutkaisiin määritystiedostoihin. Tämä tekee siitä erityisen houkuttelevan käyttöliittymäympäristöissä, joissa on jo käytössä useita työkaluja.
Jest integroituu vakiona Frontend-projektien keskeiset ominaisuudetnopea testien suoritus, tarkkailutila, joka suorittaa testit uudelleen havaitessaan muutoksia, erittäin kätevä tuki asynkroniselle koodille, simuloiduille simulaatioille ja vakoiluille sekä koodin kattavuusraporttien luominen ilman ulkoisia työkaluja.
React-käyttöliittymäprojekteissa Jest yhdistetään lähes aina seuraaviin: Reaktion testauskirjastoTämä kirjasto helpottaa komponenttien testaamista niiden käyttäytymisen ja renderöinnin kautta sen sijaan, että se olisi liian sidottu sisäiseen toteutukseen. Näiden kahden työkalun avulla voit kattaa käytännössä kaikki tavanomaiset rajapintojen testaustarpeesi.
Jest- ja React-testauskirjaston asentaminen frontend-projektiin
Ensimmäinen askel Jestin käytön aloittamiseen on sen lisääminen kehitysriippuvuutena. projektissasi. Jos käytät npm:ää, tyypillinen komento olisi:
npm asennus --save-dev jest
Jos mieluummin työskentelet langan kanssaVoit asentaa sen seuraavasti:
lanka lisää --dev jest
React-pohjaisissa projekteissa on hyvin yleistä asentaa myös React Testing Library, joka koostuu useista paketeista: peruspaketista @testing-library/react komponenteille, @testing-library/jest-dom DOM:n lisämatchereille ja usein @testing-library/user-event monimutkaisten käyttäjävuorovaikutusten simuloimiseksi.
Tyypillinen React-asetus saattaa näyttää suunnilleen tältä:
npm asennus –save-dev @testing-library/react @testing-library/jest-dom @testing-library/user-event
Kun nämä riippuvuudet ovat paikoillaan, ympäristösi on valmis kirjoittamaan komponenttikeskeisiä yksikkötestejä., tapahtumat ja tulokset käyttäjälle näkyvissä, aina Jestin ollessa tärkein testisuoritusmoottori.
Jestin peruskonfiguraatio package.json-tiedostossa
Kun Jest on asennettu, sinun on kerrottava projektille, miten testit käynnistetään.Yleinen käytäntö on lisätä package.json-tiedostoon skripti, jotta terminaalista saadaan yksinkertainen komento.
Minimalistinen esimerkki konfiguraatiosta voisi olla:
{ «skriptit»: { «testi»: «jest» } }
Tämän skriptin avulla voit suorittaa kaikki projektitestit yksinkertaisesti käynnistämällä:
npm testi
tai jos käytät lankaa,:
lankatestaus
Jest tunnistaa testitiedostot automaattisesti niiden nimen perusteellaOletusarvoisesti se etsii kansiopuustasi tiedostoja, joiden pääte on .test.js tai .spec.js, joten polkuja ei yleensä tarvitse määrittää manuaalisesti, kunhan noudatat näitä käytäntöjä.
Tiedostokäytäntö: .test.js-tiedostopääte ja testirakenne
Jotta Jest tunnistaa testisi ilman lisämäärityksiä, On erittäin suositeltavaa käyttää .test.js-laajennusta. (tai .test.ts, jos työskentelet TypeScriptin kanssa). Jos sinulla on esimerkiksi Button.jsx-komponentti, sen test-komponentin yleinen nimi olisi Button.test.js samassa hakemistossa tai erillisessä tests-kansiossa.
Tällä sopimuksella on kaksi selkeää etua:
- Toisaalta Jest paikantaa automaattisesti suoritettavat tiedostot.
- Toisaalta kuka tahansa projektissa uusi tietää heti, mitkä tiedostot sisältävät tuotantokoodia ja mitkä testejä.
Testit määritellään seuraavasti: testifunktio tai sen alias itjossa ensimmäinen argumentti on tekstikuvaus tarkistettavasta kohteesta ja toinen on funktio, joka suorittaa testilogiikan. Funktion sisällä väitteitä käytetään `expect`-muuttujassa ja sen eri vastineissa.
React-komponenteissa rakenne on samanlainenPelkän funktion testaamisen sijaan renderöit komponentin React Testing Librarylla, etsit näytöltä elementtejä (tekstin, roolin, otsikoiden jne. perusteella) ja tarkistat, että ne näkyvät tai reagoivat odotetulla tavalla käyttäjän vuorovaikutusta simuloitaessa.
Kirjoita ensimmäinen yksikkötestisi Jestillä
Tuodakseen kaiken tämän maan pinnalle, Kuvittele yksinkertainen funktio, joka laskee yhteen kaksi arvoaMäärittele tiedostossa sum.js funktio sum(a, b) { return a + b; } ja vie se. Tuo sitten funktio tiedostoon sum.test.js ja määrittele testi, jossa on selkeä kuvaus siitä, mitä pitäisi tapahtua.
Testikappale rajoittuu funktion suorittamiseen ja tuloksen validointiin.Kutsut funktiota sum(1, 2) ja käytät expect-funktiota osoittaaksesi, että arvon on oltava täsmälleen 3. Jos funktio lakkaa palauttamasta kyseistä tulosta (virheen tai odottamattoman muutoksen vuoksi), Jest merkitsee testin epäonnistuneeksi.
Tämän tyyppinen testi, vaikka se saattaakin vaikuttaa kuinka yksinkertaiselta, on yksikkötestauksen perusta.Jokaisella funktiolla tai loogisella yksiköllä on yksi tai useampi testi, jotka kuvaavat, mitä sen tulisi tehdä eri tilanteissa, jotta kaikki poikkeamat odotetusta toiminnasta ovat välittömästi havaittavissa yksinkertaisesti suorittamalla testipaketti.
Frontend-komponenteissa lähestymistapa on aivan yhtä suoraviivainenRenderöit komponentin, tarkistat näytettävän sisällön, simuloit tapahtumia, kuten klikkauksia tai syötteisiin kirjoittamista, ja validoit, että tuloksena oleva tila ja DOM vastaavat sovelluksen toiminnallista suunnittelua.
Projektin kasvaessa tulet lisäämällä testejä rajatapausten kattamiseksiepätyypilliset merkinnät, virheet ja vähemmän ilmeiset tilanteet, mikä vahvistaa sovelluksen luotettavuutta ja estää regressiot, kun otat käyttöön uusia toimintoja.
Jest Matchers: erilaisia tapoja tarkistaa tuloksia
Jest-teoksen väitteiden ydin on odotusfunktiojoka on ketjutettu eri yhteensovittimien kanssa vastaanotetun arvon vaatimusten määrittämiseksi. Testattavasta kohteesta riippuen kannattaa käyttää jompaakumpaa. Nämä ovat käytännöllisimmät yhteensovittimet:
- olla. Se tarkistaa ehdottoman yhtäsuuruuden, mikä JavaScriptissä tarkoittaa samaa arvoa ja samaa tyyppiä, mikä on erittäin hyödyllistä numeroille, merkkijonoille tai totuusarvoille, joissa odotetaan tarkkaa vastinetta. Jos odotat arvoa 3, et halua luvun "3" saapuvan.
- to EqualHyödyllinen työskenneltäessä objektien tai taulukoiden kanssa. Tämä matcher vertaa objektien rakennetta ja sisältöä, joten voit varmistaa, että funktio palauttaa objektin oikeilla ominaisuuksilla ja arvoilla, vaikka sisäinen viittaus ei olisi sama.
- ei. Jos jossain vaiheessa sinun on varmistettava, ettei jotain tapahdu, voit käyttää negaatiota `not`. Esimerkiksi `expect(value).not.toBe(0)` tekee selväksi, että luvun ei tulisi olla nolla, tai `expect(array).not.toEqual([])` osoittaa, että et odota tyhjää taulukkoa.
Näiden perusasioiden lisäksi Jest tarjoaa monia muut parinvälittäjät: tarkistetaan, että funktio heittää virheen, että taulukko sisältää tietyn elementin, että merkkijono vastaa säännöllistä lauseketta tai, kuten Reactin tapauksessa jest-dom, että DOM-elementti on näkyvissä, poistettu käytöstä, onko siinä tiettyä tekstiä jne.
Asynkroninen testaus Jestissä: promiset, async/await ja callbackit
Moderni käyttöliittymä on täynnä asynkroniset operaatiotHTTP-pyynnöt, ajastimet, käyttäjän toiminnot, jotka käynnistävät tilapäivityksiä, jne. Siksi Jest integroi useita tapoja työskennellä mukavasti asynkronisten testien kanssa.
Puhtain ja yleisin tapa testata asynkronista logiikkaa on käytä async/await-funktiotaMäärität testifunktiosi asynkroniseksi, odotat tarkistettavan promise-lauseen toteutumista ja teet sitten tavanomaiset väitteet odotus-operaattorilla vastaanotetusta tuloksesta.
Voit esimerkiksi käyttää fetchData-funktiota, joka palauttaa promise-arvon, ja kirjoittaa asynkronisen testin, joka kutsuu fetchData-funktiota, odottaa sen ratkaisua ja varmistaa, että palautettu data vastaa odotuksiasi, olipa kyseessä sitten tietty teksti tai tietyn rakenteen omaava objekti.
Jest tukee myös suoraan promiseja ilman async/await-ominaisuuttaPalauttaa itse lupauksen testistä, jotta kehys tietää, milloin operaatio on päättynyt. Lisäksi vanhemmissa tai hyvin erityisissä tapauksissa se sallii takaisinkutsujen käytön `done`-parametrilla testin päättymisen osoittamiseksi.
React-testauskirjaston alalla Asynkroniset testit yhdistävät usein waits-funktion findBy- tai waitFor-funktioon., joiden avulla voidaan odottaa DOM:n päivittymistä pyynnön tai tilanmuutoksen jälkeen ennen asiaankuuluvien väitteiden tekemistä.
Pilkkaaminen Jestissä: moduulien, funktioiden ja riippuvuuksien simulointi
Yksikkötestauksen perusperiaate on eristä testattava yksikköTämä tarkoittaa, että jos funktio tai komponentti on riippuvainen ulkoisista palveluista (APIt, kolmannen osapuolen kirjastot, raskaat moduulit jne.), sinun kannattaa simuloida näitä toimintoja sen sijaan, että suorittaisit niitä testin aikana.
Jest helpottaa tätä eristäytymistä pilkan avullajest.fn:n avulla voit luoda simuloituja funktioita, jotka tallentavat kuinka monta kertaa niitä kutsutaan, millä argumenteilla tai minkä arvon niiden tulisi palauttaa. Tämä on erittäin hyödyllistä sisäisten vuorovaikutusten testaamiseen ilman, että tarvitsee koskea näiden palveluiden varsinaiseen koodiin.
Kun sinun täytyy ottaa askel eteenpäin, jest.mockin avulla voit korvata kokonaisia moduulejaVoit määrittää, että tiettyä tiedostoa tuodessaan Jestin tulisi käyttää mallitoteutusta, joka palauttaa kontrolloituja arvoja, välttäen esimerkiksi oikeiden HTTP-pyyntöjen lähettämisen joka kerta, kun testipaketti suoritetaan.
React-komponenteissa mallinnuksia käytetään usein mukautettujen hookien simulointiin., datapalvelut tai moduulit, jotka hallitsevat paikallista tallennustilaa, analytiikkaa jne., pitäen testin keskittyvän komponentin toimintaan eikä sen ulkoisten riippuvuuksien toimintaan.
Oikein käytettynä, Pilkkaaminen nopeuttaa testien suoritusta huomattavasti. ja sen avulla voit helposti toistaa virhetilanteita, outoja palvelinvastauksia tai epätyypillisiä tiloja, joita olisi vaikea saavuttaa vuorovaikutuksessa oikeiden palveluiden kanssa.
Testien järjestäminen ja ryhmittely lohkojen avulla kuvaa
Testisarjasi kasvaessa tarvitset ylläpitää vähimmäistilausmäärää Jotta vältyttäisiin eksymästä satojen useissa tiedostoissa olevien testien joukkoon, Jest tarjoaa lohkoja luonnollisena tapana ryhmitellä toisiinsa liittyviä testejä.
Kuvauksen avulla voit liitä useita testejä samaan kontekstiinEsimerkiksi ”aritmeettiset operaatiot” tai ”Otsikkokomponentin käyttäytyminen”. Lohkon sisällä jokainen testi kuvaa tietyn tapauksen, mutta joukko on kuin yhtenäinen tarina kyseisestä koodin osasta.
Tämä organisaatio auttaa sekä lukemisessa että virheenkorjauksessa.Kun jokin menee pieleen, on helpompi paikantaa testiryhmä ja ymmärtää, mihin järjestelmän osaan se vaikuttaa, ilman että koko projektia tarvitsee käydä läpi.
Lisäksi, kuvailee yhdistyvän erittäin hyvin Jest-elinkaarikoukkujen kanssa, kuten beforeEach tai afterEach, joiden avulla voit valmistella tietoja tai tyhjentää jaettuja tiloja kaikille saman lohkon testeille, välttäen alustuslogiikan päällekkäisyyden jokaisessa yksittäisessä testissä.
Monimutkaisissa front-end-projekteissa on yleistä, että jokaisella komponentilla on oma deskriptorinsa (describe)., tarvittaessa jaettuna sisäisiin kuvauksiin eri tiloille, ominaisuuksille tai vuorovaikutusvirroille, mikä muuttaa testitiedoston melko selkeäksi kartaksi kaikesta, mitä kyseiseltä komponentilta odotetaan.
NPM-testauksen ja suorituskurin käyttö työnkulussa
Kun peruskonfiguraatio on valmis, npm-testikomennosta tulee päivittäinen liittolaisesiSen suorittaminen ennen muutosten lataamista pitäisi olla lähes automaattinen ele, kuten tiedoston tallentaminen tai linterin suorittaminen.
Monet tiimit omaksuvat kirjoittamattoman säännön, jonka mukaan ei sitouduta, jos testit epäonnistuvat.Tämä käytäntö estää projektin päähaaran rikkoutumisen ja ylläpitää taattua vähimmäislaatua jokaisessa repositorioon integroidussa yhdistämis- tai pull-pyynnössä.
Jest tarjoaa myös erittäin hyödyllinen interaktiivinen tila kehitteilläKun npm-testiä suoritetaan tarkkailutilassa, kehys suorittaa uudelleen vain muokkaamiisi tiedostoihin liittyvät testit, mikä nopeuttaa huomattavasti testaus- ja korjaussykliä, kun kehität uusia ominaisuuksia tai korjaat virheitä.
Jest-järjestelmän integrointi jatkuvaan integraatiojärjestelmään (CI) GitHub-toiminnot täydennä ympyräJoka kerta, kun joku lataa koodia etäsäilöön, CI-palvelin suorittaa npm-testin ja estää integraation, jos ohjelmistopaketti epäonnistuu, estäen virheiden pääsyn jaettuihin ympäristöihin.
Koodin kattavuus: mittaa, kuinka paljon testataan todellisuudessa
Muutaman kirjallisen kokeen pitäminen ei riitä. On myös mielenkiintoista tietää, missä määrin he kattavat koodin.Tätä tarkoitusta varten Jest integroi kattavuusraportoinnin, joka osoittaa, mitkä rivit, funktiot ja haarat on suoritettu testauksen aikana.
Näiden raporttien luominen on yhtä helppoa kuin --coverage-lipun lisääminen test-komentoon.Voit esimerkiksi määrittää package.json-skriptin muotoon "test": "jest --coverage" tai ajaa npm test --coverage, kun haluat yksityiskohtaisen raportin.
Tulos sisältää kattavuusprosentit tiedostokohtaisesti ja globaalilla tasollaNäet, millä tiedostoilla on hyvä kattavuus ja mihin ei juurikaan puututa testauksen aikana, mikä auttaa sinua päättämään, missä kannattaa panostaa ylimääräistä vaivaa useampien testien kirjoittamiseen.
Tietenkin kannattaa muistaa, että 100 %:n kattavuus ei takaa virheettömyyttäOn mahdollista ajaa kaikki koodirivit vaatimattomilla testeillä, joten väitteiden laatu on yhtä tärkeää tai jopa tärkeämpää kuin itse lukumäärä.
Käytä kattavuutta karkeana indikaattorina yhdistettynä koodikatselmuksiin ja maalaisjärkeenSe on hyvä tapa säilyttää tasapaino testaustyön ja projektin vakauden kannalta todellisten hyötyjen välillä.
Kaikella nähtyllä Jestin ja työkalujen, kuten React Testing Libraryn, käyttö frontend-projekteissa Siitä tulee melko looginen päätösSen avulla voit varmistaa, että jokainen komponentti ja funktio toimii kuten pitääkin, suorittaa testejä helposti npm-testillä, seurata kattavuutta –coverage-metodilla ja ylläpitää vankkaa koodikantaa, jossa tuotteen kehittäminen on paljon turvallisempaa ilman pelkoa jo toimineen rikkomisesta.
