Slik setter du opp Jest trinn for trinn i et eksisterende JavaScript-prosjekt

Mange prosjekter starter uten tester, så kommer behovet snikende når koden vokser og feil begynner å gjenta seg. Da er det lett å utsette oppsett av testverktøy fordi det føles tungt, teknisk og forstyrrende for pågående arbeid.

Denne guiden viser hvordan du kan innføre Jest i et eksisterende JavaScript-prosjekt uten å stoppe alt annet. Vi går gjennom konkret oppsett, en enkel struktur og noen praktiske grep som gjør det mulig å begynne smått, men nyttig, allerede i dag.

Hva er Jest, og når passer det?

Jest er et testverktøy for JavaScript og TypeScript som kjører i Node. Det egner seg godt for prosjekter som bruker React, Node eller vanlig frontendlogikk bygget med bundlere som Vite, Webpack eller Parcel.

Verktøyet passer særlig dersom du vil ha en testrunner som inkluderer det meste ut av boksen: kjøring av tester, mocking, snapshots og enkel kode-dekning (coverage). Dersom du allerede har en testrunner på plass, er det sjelden verdt å bytte bare for å bytte, men for prosjekter uten tester er Jest et trygt startpunkt.

Forbered prosjektet: sjekk hva du har fra før

Før du installerer noe, lønner det seg å sjekke nåsituasjonen. Dette hindrer konflikter og unødvendig opprydding senere.

Gjør en rask sjekk av prosjektet ditt:

• Åpnepackage.jsonog se om det allerede finnesdevDependenciesfor Jest eller andre testverktøy.
• Søk etter mapper eller filer somtest,__tests__eller filer som slutter på.test.js.
• Sjekk om det finnes npm-skript som“test”eller“test:unit”.

Hvis du finner et annet testoppsett i aktiv bruk, kan det være bedre å utvide det du allerede har, i stedet for å starte på nytt. Hvis ikke, er det fritt frem for å innføre Jest.

Installer Jest og lag et første testskript

For et vanlig Node- eller frontendprosjekt som bruker npm, kommer du i gang slik:

Installer Jest som utviklingsavhengighet:

npm install –save-dev jest

Deretter legger du til et enkelt testsystem ipackage.json:

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

Nå skal du kunne kjørenpm testuten at det krasjer, men det vil som regel ikke finne noen tester ennå. Det tar vi i neste steg.

Velg en enkel struktur for testfiler

Det finnes to hovedmønstre for hvor testene ligger i et prosjekt: enten i en egen mappe eller rett ved siden av filene de tester.

• Egen testmappe: for eksempel/testseller/__tests__med filer somuser.test.js. Gir et ryddig skille, men kan skape avstand mellom kode og tester.
• Side-om-side: testfiler ligger ved siden av kildekoden, for eksempeluser.jsoguser.test.jsi samme mappe. Gjør det lett å se hva som er testet.

For de fleste mindre og mellomstore prosjekter er side-om-side det greieste å starte med, fordi det senker terskelen for å legge til nye tester etter hvert.

Skriv din første Jest-test

La oss si du har en enkel funksjon isrc/math.js:

export function add(a, b) { return a + b }

Lag da en fil ved siden av den,src/math.test.js, med enkel testlogikk:

import { add } from ‘./math’
test(‘add legger sammen to tall’, () => {
  expect(add(2, 3)).toBe(5)
})

Nå kan du kjørenpm test. Hvis alt er satt opp riktig, skal du få grønt lys for én test. Da vet du at Jest fungerer i prosjektet ditt, og du har et konkret utgangspunkt for videre arbeid.

Grunnleggende Jest-konfigurasjon uten overstyring

I starten er det lurt å bruke så lite konfigurasjon som mulig. Jest har sensible standardvalg for rene JavaScript-prosjekter uten bundling i testløpet.

Behovet for egen konfig oppstår ofte når du:

• Bruker TypeScript eller moderne syntaks som ikke støttes direkte i Node-versjonen din.
• Importerer CSS, bilder eller andre ikke-JS-filer i koden som skal testes.
• Har en spesiell mappe- eller navnestruktur for testfiler.

Da kan du legge til en enkeljest.config.cjsellerjest.config.js. Start forsiktig, for eksempel ved kun å justere hvor testene ligger eller hva filene heter, i stedet for å kopiere store konfigurasjoner fra andre prosjekter.

Hvordan starte med tester i et eksisterende kodeberg

Det vanligste problemet i etablerte prosjekter er ikke Jest i seg selv, men at man har mye kode uten tester fra før. Her er en praktisk rekkefølge som ofte fungerer:

• Velg noen få, forretningskritiske funksjoner som er forholdsvis rene og enkle å teste.
• Skriv 1–3 små tester for hver av disse, helst uten mocking i første runde.
• Kjør testene ofte, og bak dem inn i hverdagslig utvikling før du skalerer opp.

Unngå å love full testdekning med en gang. Det er mer realistisk å bygge opp et lite, men pålitelig lag av tester rundt viktig logikk, og så utvide derfra når behov oppstår.

Vanlige feil og hvordan løse dem

Noen problemer dukker opp igjen og igjen ved første Jest-oppsett. Her er et lite oppslagsverk:

• Jest finner ingen tester: sjekk at filene heter*.test.jseller*.spec.js, og at de ligger i mapper Jest faktisk skanner.
• Node feiler på import-syntaks: hvis du brukerimportogexport, må du sikre kompatibel Node-versjon eller bruke et byggeledd, for eksempel Babel, i testløpet.
• Tester stopper på grunn av CSS eller bilder: konfigurer Jest til å mocke slike importer med en enkel stub-fil eller modul.

Når du løser en slik feil for første gang, lønner det seg å skrive en kort intern notatlinje eller dokumentere løsningen. Det sparer tid for både deg og resten av teamet neste gang.

Integrer Jest i daglig arbeidsflyt og CI

Når de første testene er på plass, handler resten om å gjøre dem til en naturlig del av utviklingsprosessen. Målet er at testing ikke skal være et eget prosjekt, men en vane.

Noen enkle grep:

• Bruknpm test — –watchlokalt for automatisk kjøring mens du oppdaterer kode.
• Legg til en enkel jobb i CI-oppsettet ditt som kjørernpm ciog deretternpm test.
• Avklar i teamet hvilken minimumsstandard dere vil ha, for eksempel at nye funksjoner skal ha minst én test.

Det er ofte bedre med et lite, stabilt testsett som alltid kjører i CI, enn et ambisiøst opplegg som bare kjøres sporadisk fordi det er tregt eller ustabilt.

Når bør du gå videre til mer avansert bruk?

Etter hvert som du blir trygg på det grunnleggende, vil du kanskje utforske flere Jest-funksjoner, som mocking av API-kall, snapshot-tester av komponenter eller mer detaljert dekning.

Ta det gradvis: hver gang du merker deg et gjentakende mønster i testene, for eksempel mye manuell mocking av samme modul, kan du vurdere om Jest eller et tilleggsverktøy tilbyr en enklere måte å gjøre det på. På den måten utvikler testoppsettet seg i takt med reelle behov, ikke teorier.