Praktisk innføring i Jest: raske og pålitelige tester for moderne JavaScript-kode

Jest har blitt standardvalget for testing i mange JavaScript- og TypeScript-miljøer. Det er raskt, integreres fint med moderne verktøykjeder og gir nyttige feilmeldinger som faktisk hjelper deg å finne problemet.

I denne artikkelen får du en praktisk gjennomgang av hvordan du tar Jest i bruk i et ekte kodebase-miljø: installasjon, grunnleggende oppsett, nyttige mønstre, vanlige feil og noen enkle rutiner som gjør testingen mindre smertefull i hverdagen.

Hva gjør Jest nyttig i daglig utviklingsarbeid

Jest er et testrammeverk for JavaScript som dekker det meste du trenger i ett verktøy: kjøring av tester, assertions, mocking og coverage. Det gjør at du slipper å sette sammen flere små biblioteker for å få et komplett oppsett.

Mange verktøy og rammeverk, som Create React App, Vite-templates og Next.js, har støtte for Jest eller lignende testverktøy. Det betyr at Jest ofte passer naturlig inn i eksisterende oppsett, spesielt hvis du har en web- eller Node-applikasjon med moduler skrevet i ES eller TypeScript.

Grunnoppsett: kom i gang med Jest i et eksisterende kodebase

Utgangspunktet her er et prosjekt medpackage.jsonogNodeinstallert. Hvis du bruker bundlere som Vite, Webpack eller esbuild, vil dette normalt fungere fint sammen med Jest så lenge du håndterer modulformat og eventuelt TypeScript.

Installer Jest lokalt i kodebasen:

• npm:npm install --save-dev jest
• Yarn:yarn add --dev jest
• pnpm:pnpm add -D jest

Legg så til et script ipackage.jsonsom gjør det enkelt å kjøre testene:

"scripts": { "test": "jest" }

Fra nå av holder det å kjøre npm test (eller tilsvarende kommando) for å starte Jest. Dette er ofte nok for rene Node-biblioteker som bruker CommonJS eller moderne ES-moduler uten byggesteg.

Navngivning og struktur: hvor bør testene ligge

Jest fungerer bra med flere ulike strategier, men to mønstre går igjen fordi de er enkle å forholde seg til i større kodebaser.

Det mest brukte er å legge testfiler ved siden av koden med et tydelig navn, for eksempelutils.test.jsved siden avutils.js. Alternativt kan du samle tester i en egen mappe somtests, for eksempeltests/utils.test.js.

Jest finner som standard filer som slutter på.test.jseller.spec.js. Velg én variant og hold deg til den, så slipper du forvirring senere. Dersom du vil bruke TypeScript, er.test.tsog.test.tsxvanlige mønstre.

Første test: enkel funksjon, enkel gevinst

Ta utgangspunkt i en liten funksjon som faktisk brukes i koden, for eksempel en datoformatterer eller en beregningsfunksjon. Dette gir rask nytteverdi i stedet for kunstige eksempler.

Anta at du har en filsum.jsmed en eksportert funksjon sum(a, b). Da kan en enkel Jest-test se slik ut:

import { sum } from './sum';
test('summerer to tall', () => {
  expect(sum(2, 3)).toBe(5);
});

Nøkkelpunkter her er attestbeskriver hva som skal skje, ogexpect(…).toBe(…)uttrykker forventningen. Når testen feiler, vil Jest vise hva som var forventet og hva som faktisk kom tilbake.

Vanlige Jest-funksjoner du bruker nesten hver dag

Det finnes mange matchere i Jest, men du trenger ikke lære alle med én gang. Noen få dekker en stor del av daglig testarbeid.

• toBefor primitive verdier, som tall og strenger
• toEqualfor objekter og arrayer
• toBeTruthy / toBeFalsyfor enkle sannhetsjekker
• toContainogtoHaveLengthfor lister og strenger
• toThrowfor funksjoner som skal kaste feil

For asynkron kode er det nyttig å kunne teste bådeasync/awaitog promise-baserte funksjoner. Da bruker duawaitsammen medresolvesellerrejects, eller lar testen selv væreasyncog venter på funksjonskallet.

Håndtering av asynkron kode uten frustrasjon

Mye moderne JavaScript svare på nettverkskall eller tidsstyrte operasjoner. Tester som sliter med asynkronitet fører ofte til flakiness eller hengende testruns. Her er noen tommelfingerregler.

La selve Jest-testen væreasync, og brukawaitpå funksjonen du vil teste. Unngå unødvendig bruk av tidtakere hvis du ikke må teste tidsavhengig atferd. Sjekk at du faktisk returnerer eller venter på promise, hvis ikke kan Jest rapportere testen som grønn selv om koden ikke er ferdig kjørt.

Når du må teste setTimeout, intervaller eller lignende, kan Jest sine fake timers ofte hjelpe. Det lar deg “spole” tiden fremover kontrollert i testen i stedet for å vente i virkeligheten.

Mocking i Jest: når og hvordan det bør brukes

Mocking gjør at du kan erstatte ekte avhengigheter med kontrollerte varianter i testmiljøet. Det er nyttig når koden snakker med eksterne API-er, databaser, filsystem eller andre ting som du ikke vil ha i enhetstester.

Jest har innebygde verktøy for å lage mocks, både for funksjoner og moduler. En vanlig tilnærming er å lage små, eksplisitte mocks for nettverkskall, og bruke Jest sin automatiske mocking med måte. For mye magi her gjør det fort vanskelig å se hva testen faktisk kontrollerer.

En praktisk strategi er å la kjernefunksjoner være ren logikk uten nettverkskall, og teste disse direkte uten mocking. Da trenger du mocking kun i lagene som faktisk snakker ut av applikasjonen, og testene blir enklere å forstå.

Jest og TypeScript: litt ekstra oppsett, mye bedre tilbakemelding

Hvis du bruker TypeScript, vil du som regel ha Jest til å kjøre testene på ferdig transpilert kode eller bruke et lag som tolker TypeScript underveis. Populære valg er å kombinere Jest medts-jesteller en lettvektsløsning medbabel-jestog passende presets.

Det viktigste er å ha en Jest-konfigurasjon som vet hvordan TypeScript-filene skal tolkes, og at du holder build-oppsett og Jest-oppsett så like som mulig. På den måten slipper du overraskelser der koden bygger fint i ett miljø, men ikke lar seg teste i et annet.

Vær også oppmerksom på at oppdateringer i TypeScript, Babel og Jest kan påvirke hverandre over tid. Det kan være lurt å sjekke dokumentasjonen for anbefalt versjonskombinasjon hvis du støter på merkelige feilmeldinger.

Raskere testrunder: watch mode og filtrering

Tester gir mest verdi når de er lette å kjøre ofte. Jest har en praktiskwatch modesom kjører relevante tester automatisk når filer endres, slik at du slipper å starte testene på nytt hver gang.

Du kan også kjøre bare én testfil av gangen, eller filtrere på testnavn. Dette er spesielt nyttig i større kodebaser der full testkjøring tar tid. Ved å la Jest fokusere på akkurat den delen du jobber med, blir feedback-løkken kortere.

Når testene begynner å vokse, kan det være nyttig å slå på coverage-rapportering i ny og ne. Det gir et overblikk over hvilke deler av koden som faktisk blir testet, og kan hjelpe deg å prioritere hvor du skal legge inn mer innsats.

Vanlige feil og enkle rutiner som redder tid

Noen typer problemer går igjen i mange kodebaser: tester som aldri avslutter, flakiness på grunn av tidtakere, eller tester som avhenger av hverandre. Disse skaper ofte mye irritasjon uten at feilen egentlig er spesielt komplisert.

En enkel rutine er å la hver test være uavhengig. BrukbeforeEachbare til tydelig initiering, og unngå delte mutable objekter som endres på tvers av tester. Når du må bruke globale variabler eller miljøkonfigurasjon, sørg for at de blir tilbakestilt etter testene, for eksempel medafterEach.

Hvis Jest rapporterer at testkjøringen ikke avslutter, er det ofte et tegn på uoppryddede timers, åpne sockets eller databindings-ressurser. I så fall kan du aktivere strengere innstillinger i Jest-konfigurasjonen som hjelper deg å identifisere hengende ressursbruk.

En liten sjekkliste for Jest i daglig bruk

• Ha et enkeltnpm test-script som alle kan kjøre likt lokalt og i CI.
• Avtal et fast testnavn-mønster, for eksempel*.test.jsved siden av koden.
• Start smått: test ren logikk først, så mer komplekse avhengigheter.
• Bruk mocking kun der du virkelig trenger å isolere eksterne avhengigheter.
• Aktiverwatchmens du utvikler, kjør full suite i CI.
• Reager når tester blir flakye, og finn årsaken tidlig før mønsteret brer om seg.

Med et bevisst oppsett og noen få gode vaner kan Jest bidra til tryggere endringer, færre regresjoner og en mer stabil hverdag for hele teamet, uten at testene føles som en egen, tung disiplin ved siden av koden.