Hopp til hovedinnhold
Versjon: 30.0

Feilsøking

Unofficial Beta Translation

This page was AI-translated by PageTurner (beta). Not officially endorsed by the project. Found an error? Report issue →

Oi sann, noe gikk galt? Bruk denne veiledningen til å løse problemer med Jest.

Tester feiler, og du vet ikke hvorfor​

Prøv å bruke feilsøkingsstøtten innebygd i Node. Plasser en debugger;-setning i en av testene dine, og kjør deretter i prosjektmappen:

node --inspect-brk node_modules/.bin/jest --runInBand [any other arguments here]
or on Windows
node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand [any other arguments here]

Dette kjører Jest i en Node-prosess som en ekstern feilsøker kan koble seg til. Merk at prosessen vil pause til feilsøkeren kobler seg til.

For feilsøking i Google Chrome (eller andre Chromium-baserte nettlesere): Åpne nettleseren og gå til chrome://inspect, klikk "Open Dedicated DevTools for Node" for å se tilgjengelige Node-instanser. Klikk på terminaladressen (som regel localhost:9229) etter å ha kjørt kommandoen over, så kan du feilsøke Jest med Chrome DevTools.

Chrome Developer Tools åpnes med et stopppunkt på første linje av Jest CLI-skriptet (dette gir deg tid til å åpne verktøyene). Klikk play-knappen øverst til høyre for å fortsette. Når Jest når debugger-setningen din, pauses kjøringen og du kan inspisere scope og kallstakk.

notat

Alternativet --runInBand sikrer at Jest kjører tester i samme prosess istedenfor å starte egne prosesser. Normalt parallelliserer Jest tester, men det er vanskelig å feilsøke flere prosesser samtidig.

Feilsøking i VS Code​

Det finnes flere måter å feilsøke Jest-tester med Visual Studio Codes innebygde feilsøker.

For å koble til den innebygde feilsøkeren, kjør testene slik:

node --inspect-brk node_modules/.bin/jest --runInBand [any other arguments here]
or on Windows
node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand [any other arguments here]

Deretter kobler du til VS Code-debuggeren ved å bruke følgende launch.json-konfigurasjon:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "attach",
      "name": "Attach",
      "port": 9229
    }
  ]
}

For å automatisk starte og koble til en prosess som kjører testene dine, bruk følgende konfigurasjon:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Jest Tests",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "--inspect-brk",
        "${workspaceRoot}/node_modules/.bin/jest",
        "--runInBand"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen"
    }
  ]
}

eller følgende for Windows:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Jest Tests",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "--inspect-brk",
        "${workspaceRoot}/node_modules/jest/bin/jest.js",
        "--runInBand"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen"
    }
  ]
}

Hvis du bruker Facebooks create-react-app, kan du feilsøke Jest-testene dine med følgende konfigurasjon:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug CRA Tests",
      "type": "node",
      "request": "launch",
      "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/react-scripts",
      "args": [
        "test",
        "--runInBand",
        "--no-cache",
        "--env=jsdom",
        "--watchAll=false"
      ],
      "cwd": "${workspaceRoot}",
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen"
    }
  ]
}

Mer informasjon om feilsøking i Node finner du her.

Feilsøking i WebStorm​

WebStorm har innebygd Jest-støtte. Les Testing With Jest in WebStorm for mer informasjon.

Problemer med hurtiglager​

Endret du transform-skriptet eller oppdaterte Babel, men endringene blir ikke oppdaget av Jest?

Prøv med --no-cache. Jest bruker hurtiglager for raskere testkjøring. Med egendefinerte transformere, vurder å legge til getCacheKey: getCacheKey i Relay.

Uløste promises​

Hvis en promise aldri løses, kan denne feilen oppstå:

- Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.

Dette skyldes vanligvis konflikt mellom Promise-implementasjoner. Erstatt den globale implementasjonen, f.eks. med globalThis.Promise = jest.requireActual('promise');, eller bruk kun ett Promise-bibliotek.

Ved langsomme tester kan du øke timeout med jest.setTimeout.

jest.setTimeout(10_000); // 10 second timeout

Problemer med Watchman​

Prøv å kjøre Jest med --no-watchman eller sett konfigurasjonsalternativet watchman til false.

Se også feilsøking for Watchman.

Tester er ekstremt trege på Docker og/eller kontinuerlig integrasjon (CI)-tjener​

Selv om Jest oftest er ekstremt rask på moderne flerkjerners maskiner med raske SSD-er, kan den være treg på enkelte oppsett som brukere har oppdaget.

Basert på funnene kan du redusere problemet og øke hastigheten med opptil 50% ved å kjøre tester sekvensielt.

For å gjøre dette kan du kjøre tester i samme tråd ved hjelp av --runInBand:

# Using Jest CLI
jest --runInBand

# Using your package manager's `test` script (e.g. with create-react-app)
npm test -- --runInBand

Et annet alternativ for å redusere testkjøringstid på CI-tjenere som Travis-CI er å sette maksimalt antall arbeidere til ~4. På Travis-CI kan dette halvere kjøringstiden. Merk: Travis CIs gratisplan for åpne kilder-prosjekter inkluderer kun 2 CPU-kjerner.

# Using Jest CLI
jest --maxWorkers=4

# Using your package manager's `test` script (e.g. with create-react-app)
npm test -- --maxWorkers=4

Hvis du bruker GitHub Actions, kan du bruke github-actions-cpu-cores for å oppdage antall prosessorer og sende dette til Jest.

- name: Get number of CPU cores
  id: cpu-cores
  uses: SimenB/github-actions-cpu-cores@v2
- name: run tests
  run: yarn jest --max-workers ${{ steps.cpu-cores.outputs.count }}

En annen mulighet er å bruke shard-flagget for å parallelisere testkjøringen på tvers av flere maskiner.

coveragePathIgnorePatterns ser ut til å ikke ha effekt​

Forsikre deg om at du ikke bruker babel-plugin-istanbul. Jest bruker Istanbul, og bestemmer selv hvilke filer som skal instrumenteres for dekning. Med babel-plugin-istanbul får alle Babel-prosesserte filer dekningskode, og blir dermed ikke ignorert av coveragePathIgnorePatterns.

Definere tester​

Tester må defineres synkront for at Jest skal kunne samle dem.

Tenk deg for eksempel at vi skrev en test slik:

// Don't do this it will not work
setTimeout(() => {
  it('passes', () => expect(1).toBe(1));
}, 0);

Når Jest kjører testen for å samle test-ene, finner den ingen fordi definisjonen skjer asynkront på neste hendelsessyklus. Dette betyr at når du bruker test.each, kan du ikke sette tabellen asynkront i beforeEach/beforeAll.

Fremdeles problemer?​

Se Hjelp.