Enhetstesting av React-komponenter, 5 enkle tips for å komme i gang

Enhetstesting av en moderne JavaScript web-applikasjon kan være vanskelig å komme i gang med. Ved å kombinere React med to kraftige test-verktøy er det raskt skrive gode enhetstester.

Pakkene vi skal bruke er:

  • Jest: Testkjører som eksekverer testene våre. Det har også funksjoner for stubbing og spying.
  • enzyme: Verktøy for å assertere, manipulere og traversere React-komponenter.

Har du lyst å komme i gang og teste eksemplene under her, så kan jeg anbefale create-react-app som kommer med Jest. Installer enzyme i tillegg så er du klar.

Eksemplene vil bestå av av en eller flere describe eller it , en typisk test fil vil importere React fra react og shallow eller mount fra enzyme.

1. Test fleste komponenter ved bruk av shallow

Når vi enhetstester så er det viktig å holde seg mest mulig til hver enhet. I vårt tilfelle er dette React-komponenter. Dersom en komponent avhengig av andre komponenter eller funksjoner så er vi ikke interessert i å teste de i tillegg. Shallow gjør dette enklere for oss ved å ikke initiere opp under-komponenter, og kjører færre livssyklus-funksjoner

Shallow vil kalle componentDidMount ved instansiering og componentWillReceiveProps dersom man oppdaterer props med .setProps() manuelt. Denne oppførselen kan man skru av ved å sende inn tilleggsvalgene { disableLifeCycleMethods: true } til shallow.

Bonustips: Bruk console.log(wrapper.debug()); til å se hvordan shallow representerer DOM-en til komponenten når du utvikler testene.

2. Eksekver kun det du tester

Test én og én funksjon i dine stateful-komponenter, disse kan nås via .instance() . Dette lar oss teste én og én funksjon i en komponent.

3. Sjekk at ting faktisk har skjedd

Jest gir oss noen verktøy for å bekrefte at det vi vil skal skje — har skjedd. jest.spyOn(...) og jest.fn() er to verktøy som lar oss gjøre nyttige sjekker på handlinger innad en komponent.

4. Mocking og stubbing

Tre forskjellige måter å gjøre ting på, avhengig av hvordan komponenten din er satt opp. Vi kan gjøre det ved å sende inn jest.fn() mock-funksjoner, mutere instansen til komponenten med våre egne implementasjoner eller å stubbe ut importerte biblioteker.

4.1. Funksjoner som sendes inn som props

I eksempelvis en redux-tilkoblet komponent så er det enklest å teste en komponent om man går helt utenom redux. Her er et eksempel på hvordan å hente ut den ikke-tilkoblede komponenten, og gi den props som redux vanligvis ville hatt ansvaret for.

4.2. Overskriv interne funksjoner for å redusere hva som testes

Vi har en stateful komponent som har to funksjoner, createPost og generateText , hvor createPost kaller på generateText . I dette scenarioet kan vi enkelt mocke ut generateText for å begrense testingen vår til createPost .

4.3. Stubbing av eksterne biblioteker

Ekstern kode kan ofte være et problem i enhetstester. De kan være store og tunge ting som gjør at testene blir trege, eller til og med gjøre det umulig for oss å få testet.

Det kan enkelt løses ved å utnytte hvordan lasting av moduler fungerer i JavaScript.

Vi har en enkel komponent:

Med tilhørende test:

Når vi kjører testen så blir crunchData fra biblioteket aldri eksekvert, som gjør testen vår lynrask, og vi tester kun funksjonaliteten i komponenten vår.

5. Testing av promises (ikke React-spesifikk)

Jeg foretrekker å holde fetching av data og transformering utenfor komponentene mine, men det er viktig å tenke over at man ikke alltid trenger Redux. Her er noen tips for håndtering av promises i enhetstester, både i og utenfor React-komponenter.

Vi tar utgangspunkt i en React komponent som henter litt data ved hjelp av fetch .

Man kan jo bli tilgitt for å tro at denne testen er umulig, eller i det minste veldig vanskelig å teste. Den gjør noe asynkront og den bruker nettverkskall! Men om vi skjønner hvordan Jest håndterer promises og hvordan vi mocker ut fetch, så blir denne veldig enkel å teste.

Dersom vi returerer et promise til Jest, så vil Jest vente til det promiset blir resolved eller rejected, fjerner vi fetch-kallet i tillegg så trenger den ikke å vente lenge. Følg kommentarene i kodesnutten under.

Håper du fant noen nyttige tips. Ser du noe feil eller er sterkt uenig, fyr av en kommentar under. :-)

// Karl

)

Thanks to Carina Louise Kristensen and Håvard Bjurholt

Karl Jørgen Overå

Written by

Systek

Systek

Systek er et IT-konsulentselskap med hovedsete i Oslo. Denne bloggen er et sted hvor våre konsulenter ytrer seg om hva vi brenner for innen teknologi og metode i IT-prosjekter.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade