Effektiv testing i JavaScript med Jest: fra første test til nyttig testrutine

Testing i JavaScript trenger ikke være tungt, tregt eller teoretisk. Med Jest kan du skrive raske, lesbare tester som faktisk hjelper deg i hverdagen, både lokalt og i CI.

I denne artikkelen går vi gjennom hvordan du får Jest på plass, hvordan du strukturerer testene dine, og hva som ofte går galt når man tar det i bruk i et eksisterende kodebaseoppsett.

Hva er Jest, og når passer det?

Jest er et testverktøy for JavaScript og TypeScript som spesielt brukes sammen med React, men det fungerer like fint for rene funksjoner, biblioteker og Node-bakender. Det inkluderer testrunner, assertions, mocking og coverage i én pakke.

Det passer godt hvis du vil ha et samlet oppsett uten å lime sammen flere småverktøy selv. Bruker du allerede et annet testrammeverk som Mocha eller Vitest, kan det likevel hende det ikke lønner seg å migrere bare for å migrere.

Grunnoppsett: få Jest til å fungere lokalt

Start med å legge Jest til i kodebasen via pakkebehandleren du allerede bruker. I et vanlig Node-miljø holder det ofte med én pakke, mens i TypeScript- eller bundler-baserte oppsett trenger du gjerne noen ekstra tilpasninger.

Et enkelt oppsett kan se slik ut i package.json, slik at du har én kort kommando å kjøre:

Eksempel:

“scripts”: { “test”: “jest” }

Hvis testene ikke plukkes opp, sjekk at filene dine heter noe med.test.jseller.spec.js, eller oppdater Jest-konfigurasjonen til å matche navnestilen du foretrekker.

Struktur på testfiler som tåler vekst

En vanlig tilnærming er å legge tester ved siden av kildekoden, for eksempelmath.jsogmath.test.jsi samme mappe. Det gjør det lett å se hva som er testet når du navigerer i editoren.

I større kodebaser kan det være mer oversiktlig med en egentestseller__tests__-mappe, speilet etter mappestrukturen ellers. Velg én modell og hold deg til den for å unngå forvirring.

Din første nyttige Jest-test

En god første test er ofte en ren funksjon med tydelig input og output. Det gir rask mestringsfølelse og fanger tidlige feil uten at du trenger å mocke nettverkskall eller DOM.

Et enkelt eksempel kan være en funksjon som beregner pris med rabatt. Test både normale verdier, grenser og gale inputverdier, i stedet for bare ett “happy path”-tilfelle.

describe, it og navngiving som faktisk hjelper

Jest organiserer tester meddescribeogit/test. Ta deg tid til gode navn, det er det du ser i terminalen når noe feiler. Unngå interne kodenavn og referanser som bare dagens team forstår.

En nyttig tommelfingerregel er å skrive testnavn som en kort setning: hva du forventer at koden gjør gitt en konkret situasjon. Da blir feilmeldinger mer lesbare i CI-loggene.

Mocking uten å skyte deg i foten

Jest har innebygd mocking viajest.fn()ogjest.mock(). Det er fristende å mocke alt som er vanskelig, men jo mer du mocker, jo mindre ligner testen på virkeligheten.

Bruk mocking primært for eksterne grenser: nettverkskall, databaser, tredjepartsklienter og tid. Prøv heller å strukturere koden slik at ren logikk kan testes uten mocking i det hele tatt.

Vanlige problemer i ekte kodebaser

I eksisterende kode vil du ofte støte på globale avhengigheter, delt state og sideeffekter som gjør tester ustabile. Da er problemet som regel strukturen i koden, ikke Jest i seg selv.

En praktisk strategi er å starte med nye funksjoner og gradvis teste gamle deler når du likevel gjør endringer. Slik slipper du å stoppe alt arbeid for å “teste alt” på én gang.

Håndtering av asynkrone tester

Asynkrone tester feiler ofte på grunn av feil bruk avasync/awaiteller manglende retur av promises. Sørg for at testen enten er merket somasyncog venter på kallet, eller at du returnerer promise direkte slik at Jest vet når den er ferdig.

Hvis testene dine henger, er en vanlig årsak at en timer eller eventlistener aldri blir ryddet opp. Bruk Jest sine hooks somafterEachogafterAlltil å lukke håndtak og nullstille globale objekter.

Coverage som styringsverktøy, ikke mål i seg selv

Jest kan generere testdekning slik at du ser hvor mye av koden som faktisk blir kjørt av testene. Dekningsprosenten kan være nyttig som indikator, men det er ikke en garanti for kvalitet.

Bruk coverage til å finne blindsoner i kritiske deler av koden, som beregninger av pris, autentisering eller tilgangskontroll. Jakten på 100 prosent kan fort gi flate, lite meningsfulle tester.

Jest i CI og pull request-arbeid

Når du har et minimum av tester på plass er neste steg å kjøre dem automatisk i CI på hver gren. De fleste CI-løsninger støtter Node direkte, så ofte handler det mest om å kjøre samme kommando som lokalt.

En enkel praksis er å gjøre det naturlig at ny eller endret funksjonalitet følges av en oppdatert test. Korte, tydelige tester som kjører raskt lokalt øker sjansen for at de faktisk blir skrevet og vedlikeholdt.

En enkel sjekkliste for en sunn Jest-rutine

For å gjøre Jest til en praktisk del av hverdagen, kan du bruke en kort sjekkliste som støtte til rutinene dine. Poenget er å redusere friksjon og unngå at testing blir et eget, tungt spor.

• Har du en enkel testscript i package.json som alle kan kjøre likt?
• Har du avtalt hvor testfiler skal ligge og hvordan de skal navngis?
• Tester du nye funksjoner samtidig som du skriver eller endrer dem?
• Unngår du unødvendig mocking der ren logikk kan testes direkte?
• Kjører testene raskt nok til at du faktisk kjører dem ofte?

Hvis du kan svare ja på det meste her, er du på god vei mot en Jest-oppsett som gir reell verdi uten å stå i veien for utviklingstempoet.