Hopp til hovedinnhold
Versjon: Neste

Konfigurering av Jest

Unofficial Beta Translation

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

Jest-filosofien er å fungere utmerket med standardinnstillinger, men noen ganger trenger du bare mer konfigurasjonskraft.

Det anbefales å definere konfigurasjonen i en dedikert JavaScript-, TypeScript- eller JSON-fil. Fila vil bli oppdaget automatisk hvis den heter jest.config.js|ts|mjs|cjs|cts|json. Du kan bruke --config-flagget for å angi en eksplisitt sti til fila.

notat

Husk at det resulterende konfigurasjonsobjektet alltid må kunne serialiseres til JSON.

Open Config Examples
  • Using defineConfig from jest you should follow this:
jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  // ... Specify options here.
});
  • You can retrieve Jest's defaults from jest-config to extend them if needed:
jest.config.js
const {defineConfig} = require('jest');
const {defaults} = require('jest-config');

module.exports = defineConfig({
  moduleDirectories: [...defaults.moduleDirectories, 'bower_components'],
});
  • When using a separate Jest config, you can also extend Jest's options from another config file if needed using mergeConfig from jest:
jest.config.js
const {defineConfig, mergeConfig} = require('jest');
const jestConfig = require('./jest.config');

module.exports = mergeConfig(
  jestConfig,
  defineConfig({
    // ... Specify options here.
  }),
);
  • If your Jest config needs to be defined as a function, you can define the config like this:
jest.config.js
const {defineConfig, mergeConfig} = require('jest');
const jestConfig = require('./jest.config');

module.exports = defineConfig(() =>
  mergeConfig(
    jestConfig,
    defineConfig({
      // ... Specify options here.
    }),
  ),
);
  • The configuration also can be stored in a JSON file as a plain object:
jest.config.json
{
  "bail": 1,
  "verbose": true
}
  • Alternatively Jest's configuration can be defined through the "jest" key in the package.json of your project:
package.json
{
  "name": "my-project",
  "jest": {
    "verbose": true
  }
}
  • Also Jest's configuration json file can be referenced through the "jest" key in the package.json of your project:
package.json
{
  "name": "my-project",
  "jest": "./path/to/config.json"
}
tips

For å lese TypeScript-konfigurasjonsfiler krever Jest som standard ts-node. Du kan overstyre dette ved å legge til en @jest-config-loader-dokblokk øverst i fila. For øyeblikket støttes ts-node og esbuild-register. Pass på at ts-node eller den spesifiserte laderen er installert.

jest.config.ts
/** @jest-config-loader ts-node */
// or
/** @jest-config-loader esbuild-register */

import {defineConfig} from 'jest';

export default defineConfig({
  verbose: true,
});

Du kan også sende alternativer til laderen, for eksempel for å aktivere transpileOnly.

jest.config.ts
/** @jest-config-loader ts-node */
/** @jest-config-loader-options {"transpileOnly": true} */

import type {defineConfig} from 'jest';

export default defineConfig({
  verbose: true,
});

Alternativer​

Referanse​

automock [boolean]​

Standard: false

Dette alternativet forteller Jest at alle importerte moduler i testene dine skal mocks automatisk. Alle moduler som brukes i testene dine vil få en erstatningsimplementasjon som bevarer API-overflaten.

Eksempel:

utils.js
export default {
  authorize: () => 'token',
  isAuthorized: secret => secret === 'wizard',
};
__tests__/automock.test.js
import utils from '../utils';

test('if utils mocked automatically', () => {
  // Public methods of `utils` are now mock functions
  expect(utils.authorize.mock).toBeTruthy();
  expect(utils.isAuthorized.mock).toBeTruthy();

  // You can provide them with your own implementation
  // or pass the expected return value
  utils.authorize.mockReturnValue('mocked_token');
  utils.isAuthorized.mockReturnValue(true);

  expect(utils.authorize()).toBe('mocked_token');
  expect(utils.isAuthorized('not_wizard')).toBeTruthy();
});
notat

Node-moduler mocks automatisk når du har en manuell mock på plass (f.eks. __mocks__/lodash.js). Mer informasjon her.

Node.js-kjernemoduler som fs mocks ikke som standard. De kan mocks eksplisitt med jest.mock('fs').

bail [number | boolean]​

Standard: 0

Som standard kjører Jest alle tester og viser alle feil i konsollen når kjøringen er fullført. Bail-konfigurasjonsalternativet kan brukes for å få Jest til å stoppe testkjøringen etter n feil. Å sette bail til true tilsvarer å sette bail til 1.

cacheDirectory [string]​

Standard: "/tmp/<path>"

Katalogen der Jest skal lagre cachelagret avhengighetsinformasjon.

Jest prøver å skanne avhengighetstreet ditt én gang (på forhånd) og lagrer det i buffer for å redusere deler av filsystemaktiviteten som skjer under testkjøring. Denne konfigurasjonsvalget lar deg tilpasse hvor Jest lagrer disse bufferdataene på disken.

clearMocks [boolean]​

Standard: false

Tømmer automatisk mock-kall, instanser, kontekster og resultater før hver test. Tilsvarer å kalle jest.clearAllMocks() før hver test. Dette fjerner ikke mock-implementasjoner som kan ha blitt satt opp.

collectCoverage [boolean]​

Standard: false

Angir om dekningsinformasjon skal samles inn under testkjøring. Siden dette tilrettelegger alle utførte filer med dekningsinnsamlingssetninger, kan det betydelig senke testhastigheten.

Jest leveres med to dekningsleverandører: babel (standard) og v8. Se valget coverageProvider for flere detaljer.

info

Dekningsleverandørene babel og v8 bruker henholdsvis /* istanbul ignore next */ og /* c8 ignore next */ for å ekskludere linjer fra dekningsrapporter. For mer informasjon, se dokumentasjonen for istanbuljs og c8.

collectCoverageFrom [array]​

Standard: undefined

En array med glob-mønstre som angir hvilke filer dekningsinformasjon skal samles for. Hvis en fil samsvarer med det angitte glob-mønsteret, vil dekningsinformasjon bli samlet selv om det ikke finnes tester for filen og den aldri blir brukt i testsuiten.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  collectCoverageFrom: [
    '**/*.{js,jsx}',
    '!**/node_modules/**',
    '!**/vendor/**',
  ],
});

Dette vil samle dekningsinformasjon for alle filer i prosjektets rootDir, unntatt de som samsvarer med **/node_modules/** eller **/vendor/**.

tips

Hvert glob-mønster brukes i rekkefølgen de er angitt i konfigurasjonen. For eksempel vil ["!**/__tests__/**", "**/*.js"] ikke ekskludere __tests__ fordi negasjonen overskrives med det andre mønsteret. For at negert glob skal fungere i dette eksempelet må det komme etter **/*.js.

notat

Dette valget krever at collectCoverage er satt til true eller at Jest kjøres med --coverage.

Help:

If you are seeing coverage output such as...

=============================== Coverage summary ===============================
Statements   : Unknown% ( 0/0 )
Branches     : Unknown% ( 0/0 )
Functions    : Unknown% ( 0/0 )
Lines        : Unknown% ( 0/0 )
================================================================================
Jest: Coverage data for global was not found.

Most likely your glob patterns are not matching any files. Refer to the micromatch documentation to ensure your globs are compatible.

coverageDirectory [string]​

Standard: undefined

Mappen der Jest skal lagre dekningsrapporter.

coveragePathIgnorePatterns [array<string>]​

Default: ["/node_modules/"]

En array med regex-mønstre som sjekkes mot alle filstier før testkjøring. Hvis filstien samsvarer med noen av mønstrene, vil dekningsinformasjon hoppes over.

Disse mønstrene sammenlignes med hele stien. Bruk strengtokenet <rootDir> for å inkludere stien til prosjektets rotmappe for å forhindre at den ved et uhell ignorerer alle filene dine i forskjellige miljøer som kan ha ulike rotkataloger. Eksempel: ["<rootDir>/build/", "<rootDir>/node_modules/"].

coverageProvider [string]​

Angir hvilken leverandør som skal brukes for kodeinstrumentering. Tillatte verdier er babel (standard) eller v8.

coverageReporters [array<string | [string, options]>]​

Standard: ["clover", "json", "lcov", "text"]

En liste over reporter-navn som Jest bruker når den skriver dekningsrapporter. Enhver istanbul reporter kan brukes.

tips

Hvis du setter dette alternativet, overskriver du standardverdiene. Legg til "text" eller "text-summary" for å se en dekningssammendrag i konsollutdataene.

Ytterligere alternativer kan sendes ved hjelp av tuppelform. For eksempel kan du skjule dekningsrapportlinjer for fullstendig dekede filer:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  coverageReporters: ['clover', 'json', 'lcov', ['text', {skipFull: true}]],
});

For mer informasjon om alternativobjektets struktur, se typen CoverageReporterWithOptions i typedefinisjonene.

coverageThreshold [object]​

Standard: undefined

Dette brukes til å konfigurere minstekrav for dekningsresultater. Krav kan spesifiseres som global, som en glob, eller som en katalog- eller filsti. Hvis kravene ikke oppfylles, vil Jest feile. Krav spesifisert som positive tall tolkes som minsteprosentandelen som kreves. Krav spesifisert som negative tall representerer maksimalt antall udekkede enheter som tillates.

For eksempel, med følgende konfigurasjon vil Jest feile hvis det er mindre enn 80% gren-, linje- og funksjonsdekning, eller hvis det er mer enn 10 udekkede setninger:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  coverageThreshold: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: -10,
    },
  },
});

Hvis glober eller stier er spesifisert sammen med global, trekkes dekningsdata for samsvarende stier fra den totale dekningen, og krav vil bli anvendt uavhengig. Krav for glober gjelder alle filer som samsvarer med globen. Hvis filen spesifisert av stien ikke finnes, returneres en feil.

For eksempel, med følgende konfigurasjon:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  coverageThreshold: {
    global: {
      branches: 50,
      functions: 50,
      lines: 50,
      statements: 50,
    },
    './src/components/': {
      branches: 40,
      statements: 40,
    },
    './src/reducers/**/*.js': {
      statements: 90,
    },
    './src/api/very-important-module.js': {
      branches: 100,
      functions: 100,
      lines: 100,
      statements: 100,
    },
  },
});

Vil Jest feile hvis:

  • Katalogen ./src/components har mindre enn 40% gren- eller setningsdekning.

  • Én av filene som samsvarer med globen ./src/reducers/**/*.js har mindre enn 90% setningsdekning.

  • Filen ./src/api/very-important-module.js har mindre enn 100% dekning.

  • Alle gjenværende filer til sammen har mindre enn 50% dekning (global).

dependencyExtractor [string]​

Standard: undefined

Dette alternativet tillater bruk av en egendefinert avhengighetsuttrekker. Det må være en node-modul som eksporterer et objekt med en extract-funksjon. F.eks.:

const crypto = require('crypto');
const fs = require('fs');

module.exports = {
  extract(code, filePath, defaultExtract) {
    const deps = defaultExtract(code, filePath);
    // Scan the file and add dependencies in `deps` (which is a `Set`)
    return deps;
  },
  getCacheKey() {
    return crypto
      .createHash('md5')
      .update(fs.readFileSync(__filename))
      .digest('hex');
  },
};

extract-funksjonen bør returnere en itererbar (Array, Set, etc.) med avhengighetene funnet i koden.

Modulen kan også inneholde en getCacheKey-funksjon for å generere en hurtiglagsnøkkel for å avgjøre om logikken har endret seg og om cachelagrete artefakter som er avhengige av den, skal forkastes.

displayName [string, object]​

Standard: undefined

Tillater at et etikett skrives ut sammen med en test mens den kjører. Dette er spesielt nyttig i flerprosjekts-arkiver hvor det kan være mange Jest-konfigurasjonsfiler. Dette viser visuelt hvilket prosjekt en test tilhører.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  displayName: 'CLIENT',
});

Alternativt kan et objekt med egenskapene name og color sendes. Dette tillater egendefinert konfigurasjon av bakgrunnsfargen til displayName. displayName er standard hvit når verdien er en streng. Jest bruker chalk for å levere farger. Derfor er alle gyldige fargealternativ som støttes av chalk også støttet av Jest.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  displayName: {
    name: 'CLIENT',
    color: 'blue',
  },
});

errorOnDeprecated [boolean]​

Standard: false

Gjør at kall til utdaterte APIer kaster hjelpsomme feilmeldinger. Nyttig for å lette oppgraderingsprosessen.

extensionsToTreatAsEsm [array<string>]​

Standard: []

Jest vil kjøre .mjs og .js-filer hvor nærmeste package.json har type-feltet satt til module som ECMAScript Modules. Hvis du har andre filer som skal kjøres med native ESM, må du spesifisere filendelsen her.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  extensionsToTreatAsEsm: ['.ts'],
});

Jests støtte for ESM er fortsatt eksperimentell, se dokumentasjonen for mer informasjon.

fakeTimers [object]​

Standard: {}

Falske klokker kan være nyttige når kode har lange tidsavbrudd du ikke vil vente på i tester. Se Falske klokker-guiden og API-dokumentasjonen for detaljer.

Dette alternativet gir standardkonfigurasjonen for falske klokker i alle tester. Å kalle jest.useFakeTimers() i en testfil vil bruke disse innstillingene eller overstyre dem hvis et konfigurasjonsobjekt sendes med. For eksempel kan du bevare originalimplementasjonen av process.nextTick() og justere grensen for rekursive timere som vil kjøres:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  fakeTimers: {
    doNotFake: ['nextTick'],
    timerLimit: 1000,
  },
});
fakeTime.test.js
// install fake timers for this file using the options from Jest configuration
jest.useFakeTimers();

test('increase the limit of recursive timers for this and following tests', () => {
  jest.useFakeTimers({timerLimit: 5000});
  // ...
});
tips

I stedet for å inkludere jest.useFakeTimers() i hver testfil, kan du aktivere falske timere globalt for alle tester i Jest-konfigurasjonen din:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  fakeTimers: {
    enableGlobally: true,
  },
});

Konfigurasjonsalternativer:

type FakeableAPI =
  | 'Date'
  | 'hrtime'
  | 'nextTick'
  | 'performance'
  | 'queueMicrotask'
  | 'requestAnimationFrame'
  | 'cancelAnimationFrame'
  | 'requestIdleCallback'
  | 'cancelIdleCallback'
  | 'setImmediate'
  | 'clearImmediate'
  | 'setInterval'
  | 'clearInterval'
  | 'setTimeout'
  | 'clearTimeout';

type ModernFakeTimersConfig = {
  /**
   * If set to `true` all timers will be advanced automatically by 20 milliseconds
   * every 20 milliseconds. A custom time delta may be provided by passing a number.
   * The default is `false`.
   */
  advanceTimers?: boolean | number;
  /**
   * List of names of APIs that should not be faked. The default is `[]`, meaning
   * all APIs are faked.
   */
  doNotFake?: Array<FakeableAPI>;
  /** Whether fake timers should be enabled for all test files. The default is `false`. */
  enableGlobally?: boolean;
  /**
   * Use the old fake timers implementation instead of one backed by `@sinonjs/fake-timers`.
   * The default is `false`.
   */
  legacyFakeTimers?: boolean;
  /** Sets current system time to be used by fake timers, in milliseconds. The default is `Date.now()`. */
  now?: number;
  /** Maximum number of recursive timers that will be run. The default is `100_000` timers. */
  timerLimit?: number;
};
Foreldete falske timere

Av en eller annen grunn må du kanskje bruke foreldet implementering av falske timere. Slik aktiverer du det globalt (tilleggsalternativer støttes ikke):

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  fakeTimers: {
    enableGlobally: true,
    legacyFakeTimers: true,
  },
});

forceCoverageMatch [array<string>]​

Standard: ['']

Testfiler ekskluderes normalt fra dekningsanalyse. Med dette alternativet kan du overstyre dette og inkludere filer som ellers ville blitt ignorert.

For eksempel, hvis du har tester i kildefiler med .t.js-endelse slik:

sum.t.js
export function sum(a, b) {
  return a + b;
}

if (process.env.NODE_ENV === 'test') {
  test('sum', () => {
    expect(sum(1, 2)).toBe(3);
  });
}

Kan du samle dekningsdata fra disse filene ved å sette forceCoverageMatch.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  forceCoverageMatch: ['**/*.t.js'],
});

globals [object]​

Standard: {}

Et sett med globale variabler som må være tilgjengelige i alle testmiljøer.

For eksempel vil følgende opprette en global __DEV__-variabel satt til true i alle testmiljøer:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  globals: {
    __DEV__: true,
  },
});

Hvis du spesifiserer en global referanseverdi (som et objekt eller array) her, og kode muterer denne verdien under testkjøring, vil ikke endringen være gjeldende på tvers av testkjøringer for andre testfiler. I tillegg må globals-objektet være JSON-serialiserbart, så det kan ikke brukes til globale funksjoner. Bruk setupFiles for det.

globalSetup [string]​

Standard: undefined

Denne muligheten lar deg bruke en egendefinert global oppsettsmodul som må eksportere en funksjon (den kan være synkron eller asynkron). Funksjonen vil utløses én gang før alle testsuiten og vil motta to argumenter: Jest sin globalConfig og projectConfig.

info

En global oppsettsmodul konfigurert i et prosjekt (ved bruk av multi-prosjekt runner) vil kun utløses når du kjører minst én test fra dette prosjektet.

Globale variabler definert gjennom globalSetup kan kun leses i globalTeardown. Du kan ikke hente globale variabler definert her i dine testsuitene.

Mens kode-transformasjon brukes på den tilknyttede oppsettsfilen, vil Jest ikke transformere kode i node_modules. Dette skyldes behovet for å laste faktiske transformatorer (f.eks. babel eller typescript) for å utføre transformasjonen.

setup.js
module.exports = async function (globalConfig, projectConfig) {
  console.log(globalConfig.testPathPatterns);
  console.log(projectConfig.cache);

  // Set reference to mongod in order to close the server during teardown.
  globalThis.__MONGOD__ = mongod;
};
teardown.js
module.exports = async function (globalConfig, projectConfig) {
  console.log(globalConfig.testPathPatterns);
  console.log(projectConfig.cache);

  await globalThis.__MONGOD__.stop();
};

globalTeardown [string]​

Standard: undefined

Denne muligheten lar deg bruke en egendefinert global nedrydningsmodul som må eksportere en funksjon (den kan være synkron eller asynkron). Funksjonen vil utløses én gang etter alle testsuiten og vil motta to argumenter: Jest sin globalConfig og projectConfig.

info

En global nedrydningsmodul konfigurert i et prosjekt (ved bruk av multi-prosjekt runner) vil kun utløses når du kjører minst én test fra dette prosjektet.

Samme begrensning gjelder for transformasjon av node_modules som for globalSetup, og gjelder også for globalTeardown.

::>

haste [object]​

Standard: undefined

Dette brukes til å konfigurere oppførselen til jest-haste-map, Jest sitt interne filkryper-/cachesystem. Følgende alternativer støttes:

type HasteConfig = {
  /** Whether to hash files using SHA-1. */
  computeSha1?: boolean;
  /** The platform to use as the default, e.g. 'ios'. */
  defaultPlatform?: string | null;
  /** Force use of Node's `fs` APIs rather than shelling out to `find` */
  forceNodeFilesystemAPI?: boolean;
  /**
   * Whether to follow symlinks when crawling for files.
   *   This options cannot be used in projects which use watchman.
   *   Projects with `watchman` set to true will error if this option is set to true.
   */
  enableSymlinks?: boolean;
  /** Path to a custom implementation of Haste. */
  hasteImplModulePath?: string;
  /** All platforms to target, e.g ['ios', 'android']. */
  platforms?: Array<string>;
  /** Whether to throw an error on module collision. */
  throwOnModuleCollision?: boolean;
  /** Custom HasteMap module */
  hasteMapModulePath?: string;
  /** Whether to retain all files, allowing e.g. search for tests in `node_modules`. */
  retainAllFiles?: boolean;
};

injectGlobals [boolean]​

Standard: true

Setter Jest sine globale variabler (expect, test, describe, beforeEach osv.) inn i det globale miljøet. Hvis du setter dette til false, må du importere fra @jest/globals, f.eks.

import {expect, jest, test} from '@jest/globals';

jest.useFakeTimers();

test('some test', () => {
  expect(Date.now()).toBe(0);
});
notat

Dette alternativet støttes kun med standard testrunner jest-circus.

maxConcurrency [number]​

Standardverdi: 5

Et tall som begrenser antall tester som kan kjøres samtidig ved bruk av test.concurrent. Tester over denne grensen vil bli satt i kø og kjørt når en plass blir ledig.

maxWorkers [number | string]​

Angir maksimalt antall arbeidere som worker-poolen skal starte for å kjøre tester. I enkeltkjøringsmodus er standardverdien antall kjerner på maskinen din minus én for hovedtråden. I overvåkingsmodus er standardverdien halvparten av tilgjengelige kjerner for å sikre at Jest ikke forstyrrer og belaster maskinen for mye. Det kan være nyttig å justere dette i ressursbegrensede miljøer som CI, men standardinnstillingene bør være tilstrekkelige for de fleste brukstilfeller.

For miljøer med variabelt antall tilgjengelige CPU-er kan du bruke prosentbasert konfigurasjon:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  maxWorkers: '50%',
});

moduleDirectories [array<string>]​

Standard: ["node_modules"]

En matrise med mappenavn som skal søkes rekursivt opp fra plasseringen til modulen som kreves. Å sette dette alternativet vil overstyre standarden. Hvis du ønsker å fortsette å søke i node_modules for pakker, inkluder det sammen med andre alternativer:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  moduleDirectories: ['node_modules', 'bower_components'],
});
advarsel

Det frarådes å bruke '.' som en av moduleDirectories, fordi dette forhindrer scoped-pakker som @emotion/react fra å få tilgang til pakker med samme undermappnavn (react). Se denne saken for flere detaljer. I de fleste tilfeller er det å foretrekke å bruke moduleNameMapper-konfigurasjonen istedenfor.

moduleFileExtensions [array<string>]​

Standard: ["js", "mjs", "cjs", "jsx", "ts", "mts", "cts", "tsx", "json", "node"]

En array med filendelser som modulene dine bruker. Hvis du krever moduler uten å spesifisere filendelse, vil Jest se etter disse endelsene i venstre-til-høyre-rekkefølge.

Vi anbefaler å plassere de mest brukte filendelsene i prosjektet ditt lengst til venstre. Hvis du bruker TypeScript, bør du vurdere å flytte "ts" og/eller "tsx" til starten av arrayen.

moduleNameMapper [object<string, string | array<string>>]​

Standard: null

En mapping fra regulære uttrykk til modulnavn eller arrays av modulnavn som lar deg erstatte ressurser som bilder eller stiler med en enkelt modul.

Moduler som er mappet til et alias blir ikke mocket som standard, uavhengig av om automocking er aktivert eller ikke.

Bruk <rootDir>-strengtoken for å referere til rootDir-verdien hvis du ønsker å bruke filstier.

I tillegg kan du erstatte fangede regex-grupper ved hjelp av nummererte backreferanser.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  moduleNameMapper: {
    '^image![a-zA-Z0-9$_-]+$': 'GlobalImageStub',
    '^[./a-zA-Z0-9$_-]+\\.png$': '<rootDir>/RelativeImageStub.js',
    'module_name_(.*)': '<rootDir>/substituted_module_$1.js',
    'assets/(.*)': [
      '<rootDir>/images/$1',
      '<rootDir>/photos/$1',
      '<rootDir>/recipes/$1',
    ],
  },
});

Rekkefølgen mappingene defineres i har betydning. Mønstre sjekkes én etter én til et passer. Den mest spesifikke regelen bør listes først. Dette gjelder også for arrays med modulnavn.

info

Hvis du oppgir modulnavn uten grenser ^$, kan det føre til vanskelige å oppdage feil. F.eks. vil relay erstatte alle moduler som inneholder relay som en delstreng i navnet: relay, react-relay og graphql-relay vil alle pekes til din stub.

modulePathIgnorePatterns [array<string>]​

Standard: []

En array med regex-mønsterstrenger som matches mot alle modulstier før disse stiene anses som "synlige" for modullasteren. Hvis en moduls sti matcher noen av mønstrene, vil den ikke kunne require()-es i testmiljøet.

Disse mønstrene matches mot hele stien. Bruk <rootDir>-strengen for å inkludere prosjektrotkatalogen og unngå utilsiktet ignorering av filer på tvers av miljøer med ulike rotkataloger.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  modulePathIgnorePatterns: ['<rootDir>/build/'],
});

modulePaths [array<string>]​

Standard: []

Et alternativ til å sette NODE_PATH-miljøvariabelen. modulePaths er en array med absolutte stier til tilleggslokasjoner som skal søkes ved moduloppløsning. Bruk <rootDir>-strengtoken for å inkludere stien til prosjektets rotmappe.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  modulePaths: ['<rootDir>/app/'],
});

notify [boolean]​

Standard: false

Aktiverer native OS-varsler for testresultater. For å vise varslingene trenger Jest node-notifier-pakken, som må installeres ekstra:

npm install --save-dev node-notifier
tips

På macOS må du huske å tillate varsler fra terminal-notifier under Systeminnstillinger > Varslinger og fokus.

På Windows oppretter node-notifier en ny startmenyoppføring ved første bruk og viser ikke varselet. Varslinger vil vises riktig på påfølgende kjøringer.

notifyMode [string]​

Standard: failure-change

Spesifiserer varslingsmodus. Krever notify: true.

Moduser​

  • always: sender alltid et varsel.

  • failure: sender et varsel når tester feiler.

  • success: sender et varsel når tester lykkes.

  • change: sender et varsel når statusen endres.

  • success-change: sender et varsel når tester lykkes, eller én gang når de feiler.

  • failure-change: sender et varsel når tester feiler, eller én gang når de lykkes.

openHandlesTimeout [number]​

Standard: 1000

Skriver ut en advarsel om sannsynlige åpne håndteringer hvis Jest ikke avslutter skikkelig innen dette antallet millisekunder etter fullføring. Bruk 0 for å deaktivere advarselen.

preset [string]​

Standard: undefined

En forhåndsinnstilling som brukes som grunnlag for Jests konfigurasjon. En preset må peke til en npm-modul som har en jest-preset.json, jest-preset.js, jest-preset.cjs eller jest-preset.mjs-fil i roten.

For eksempel vil denne preset-en foo-bar/jest-preset.js bli brukt slik:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  preset: 'foo-bar',
});

Presets kan også være relative filsystemstier:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  preset: './node_modules/foo-bar/jest-preset.js',
});
info

Hvis du også har spesifisert rootDir, vil oppløsningen av denne filen være relativ til den rotkatalogen.

prettierPath [string]​

Standard: 'prettier'

Setter banen til prettier-nodemodulen som brukes for å oppdatere inline-øyeblikksbilder.

projects [array<string | ProjectConfig>]​

Standard: undefined

Når projects-konfigurasjonen leveres med en matrise av baner eller glob-mønstre, vil Jest kjøre tester i alle spesifiserte prosjekter samtidig. Dette er ideelt for monorepoer eller ved arbeid med flere prosjekter samtidig.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  projects: ['<rootDir>', '<rootDir>/examples/*'],
});

Denne eksempelkonfigurasjonen vil kjøre Jest i rotkatalogen og i hver mappe i eksempelkatalogen. Du kan ha ubegrenset antall prosjekter kjørende i samme Jest-instans.

Prosjektfunksjonaliteten kan også brukes til å kjøre flere konfigurasjoner eller flere runnere. For dette formålet kan du sende en matrise med konfigurasjonsobjekter. For eksempel for å kjøre både tester og ESLint (via jest-runner-eslint) i samme Jest-kjøring:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  projects: [
    {
      displayName: 'test',
    },
    {
      displayName: 'lint',
      runner: 'jest-runner-eslint',
      testMatch: ['<rootDir>/**/*.js'],
    },
  ],
});
tips

Ved bruk av multi-prosjekt runner anbefales det å legge til displayName for hvert prosjekt. Dette vil vise prosjektets displayName ved siden av dets tester.

notat

Med projects-alternativet aktivert vil Jest kopiere rotnivå-konfigurasjonsalternativer til hver enkelt underkonfigurasjon under testkjøring, og løse verdiene i barnets kontekst. Dette betyr at strengtokens som <rootDir> vil peke til barnets rotkatalog selv om de er definert i rotnivå-konfigurasjonen.

randomize [boolean]​

Standard: false

Tilsvarer --randomize-flagget for å tilfeldiggjøre rekkefølgen på tester i en fil.

reporters [array<moduleName | [moduleName, options]>]​

Standard: undefined

Bruk dette konfigurasjonsalternativet for å legge til rapporteringsverktøy i Jest. Det må være en liste over rapporteringsverktøynavn. Tilleggsalternativer kan sendes til et rapporteringsverktøy ved å bruke tuple-formen:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  reporters: [
    'default',
    ['<rootDir>/custom-reporter.js', {banana: 'yes', pineapple: 'no'}],
  ],
});

Standardrapportør​

Hvis egendefinerte rapportører er spesifisert, vil standard Jest-rapportøren bli overskrevet. Hvis du ønsker å beholde den, må 'default' sendes som rapportørnavn:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  reporters: [
    'default',
    ['jest-junit', {outputDirectory: 'reports', outputName: 'report.xml'}],
  ],
});

GitHub Actions-rapportør​

Hvis inkludert i listen, vil den innebygde GitHub Actions-rapportøren merke endrede filer med feilmeldinger fra tester og (hvis brukt med 'silent: false') skrive ut logger med GitHub-gruppefunksjoner for enkel navigering. Merk at 'default' ikke bør brukes i dette tilfellet da 'github-actions' allerede håndterer dette, så husk å også inkludere 'summary'. Hvis du kun ønsker å bruke den for annoteringer, lar du enkelt stå igjen kun rapportøren uten alternativer da standardverdien for 'silent' er 'true':

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  reporters: [['github-actions', {silent: false}], 'summary'],
});

Sammendragramsrapportør​

Sammendragramsrapportøren skriver ut en oppsummering av alle tester. Den er en del av standardrapportøren, og vil derfor være aktivert hvis 'default' er inkludert i listen. For eksempel kan du ønske å bruke den som en frittstående rapportør i stedet for standarden, eller sammen med Stille Rapportør:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  reporters: ['jest-silent-reporter', 'summary'],
});

summary-rapportøren godtar alternativer. Siden den er inkludert i default-rapportøren kan du også sende alternativene der.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  reporters: [['default', {summaryThreshold: 10}]],
});

summaryThreshold-alternativet oppfører seg på følgende måte: hvis det totale antallet testsuiter overstiger denne terskelen, vil en detaljert oppsummering av alle mislykkede tester skrives ut etter utførelse av alle testene. Standardverdien er 20.

Egendefinerte rapportører​

tips

Sulten etter rapportører? Ta en titt på den lange listen med fantastiske rapportører fra Awesome Jest.

Moduler for egendefinerte rapportører må eksportere en klasse som tar globalConfig, reporterOptions og reporterContext som konstruktørargumenter:

custom-reporter.js
class CustomReporter {
  constructor(globalConfig, reporterOptions, reporterContext) {
    this._globalConfig = globalConfig;
    this._options = reporterOptions;
    this._context = reporterContext;
  }

  onRunComplete(testContexts, results) {
    console.log('Custom reporter output:');
    console.log('global config:', this._globalConfig);
    console.log('options for this reporter from Jest config:', this._options);
    console.log('reporter context passed from test scheduler:', this._context);
  }

  // Optionally, reporters can force Jest to exit with non zero code by returning
  // an `Error` from `getLastError()` method.
  getLastError() {
    if (this._shouldFail) {
      return new Error('Custom error reported!');
    }
  }
}

module.exports = CustomReporter;
notat

For fullstendig liste over kroker og argumenttyper, se Reporter-grensesnittet i packages/jest-reporters/src/types.ts.

resetMocks [boolean]​

Standard: false

Tilbakestiller automatisk mocktilstand før hver test. Tilsvarer å kalle jest.resetAllMocks() før hver test. Dette vil føre til at alle mocks fjerner sine falske implementeringer, men gjenoppretter ikke deres opprinnelige implementering.

resetModules [boolean]​

Standard: false

Som standard får hver testfil sitt eget uavhengige modulregister. Aktivering av resetModules går et skritt videre og tilbakestiller modulregisteret før hver enkelt test kjøres. Dette er nyttig for å isolere moduler for hver test slik at lokal modultilstand ikke kommer i konflikt mellom tester. Dette kan gjøres programmatisk ved å bruke jest.resetModules().

resolver [string]​

Standard: undefined

Dette alternativet tillater bruk av en egendefinert resolver. Denne resolvere må være en modul som eksporterer enten:

  1. en funksjon som forventer en streng som første argument for banen som skal løses og et alternativobjekt som andre argument. Funksjonen skal enten returnere en bane til modulen som skal løses eller kaste en feil hvis modulen ikke kan finnes. eller

  2. et objekt som inneholder async og/eller sync egenskaper. sync-egenskapen skal være en funksjon med formen beskrevet ovenfor, og async-egenskapen skal også være en funksjon som aksepterer de samme argumentene, men returnerer et løfte som løses med banen til modulen eller avviser med en feil.

Alternativobjektet gitt til resolvere har formen:

type ResolverOptions = {
  /** Directory to begin resolving from. */
  basedir: string;
  /** List of export conditions. */
  conditions?: Array<string>;
  /** Instance of default resolver. */
  defaultResolver: (path: string, options: ResolverOptions) => string;
  /** List of file extensions to search in order. */
  extensions?: Array<string>;
  /** List of directory names to be looked up for modules recursively. */
  moduleDirectory?: Array<string>;
  /** List of `require.paths` to use if nothing is found in `node_modules`. */
  paths?: Array<string>;
  /** Current root directory. */
  rootDir?: string;
};

defaultResolver som sendes som et alternativ er Jest sin standard resolver som kan være nyttig når du skriver din egen tilpassede. Den tar de samme argumentene som din egendefinerte synkrone resolver, f.eks. (path, options) og returnerer en streng eller kaster en feil.

For eksempel, hvis du ønsker å respektere Browserifys "browser"-felt, kan du bruke følgende resolver:

resolver.js
const browserResolve = require('browser-resolve');

module.exports = browserResolve.sync;

Og legge den til i Jest-konfigurasjonen:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  resolver: '<rootDir>/resolver.js',
});

Jest sin jest-resolve er avhengig av unrs-resolver. Vi kan sende med tilleggsalternativer, for eksempel å endre mainFields for oppløsning. For React Native-prosjekter kan du for eksempel bruke denne konfigurasjonen:

module.exports = (path, options) => {
  // Call the defaultResolver, so we leverage its cache, error handling, etc.
  return options.defaultResolver(path, {
    ...options,
    // `unrs-resolver` option: https://github.com/unrs/unrs-resolver#main-field
    mainFields: ['react-native', 'main'],
  });
};

Du kan også bruke defaultResolver til å implementere en "forbehandlingsprosess" som lar oss endre hvordan standardresolveren løser moduler. For eksempel, tenk deg et TypeScript-prosjekt som trenger å referere til .js-filer under kjøring, men kjører Jest på .ts-filene.

module.exports = (path, options) => {
  // Dynamic imports within our codebase that reference .js need to reference
  // .ts during tests.
  if (
    !options.basedir.includes('node_modules') &&
    path.endsWith('.js') &&
    (path.startsWith('../') || path.startsWith('./'))
  ) {
    path = path.replace(/\.js$/, '.ts');
  }

  // Call the defaultResolver, so we leverage its cache, error handling, etc.
  return options.defaultResolver(path, options);
};

restoreMocks [boolean]​

Standard: false

Gjenopprett automatisk mock-tilstand og implementering før hver test. Tilsvarer å kalle jest.restoreAllMocks() før hver test. Dette fjerner falske implementeringer fra alle mocks og gjenoppretter deres opprinnelige oppførsel.

rootDir [string]​

Standard: Rotkatalogen som inneholder din Jest-konfigurasjonsfil eller package.json eller pwd hvis ingen package.json finnes

Rotkatalogen som Jest skal skanne etter tester og moduler. Hvis du plasserer Jest-konfigurasjonen din i package.json og vil at rotkatalogen skal være repoets rot, vil standardverdien for denne innstillingen være katalogen der package.json ligger.

Ofte vil du sette denne til 'src' eller 'lib', avhengig av hvor koden er lagret i ditt repo.

Bruk av '<rootDir>' som strengtoken i andre banebaserte innstillinger vil referere tilbake til denne verdien. For eksempel, hvis du vil at en setupFiles-oppføring skal peke til some-setup.js i prosjektroten, sett verdien til: '<rootDir>/some-setup.js'.

roots [array<string>]​

Standard: ["<rootDir>"]

En liste over baner til kataloger som Jest skal søke etter filer i.

Noen ganger ønsker du bare at Jest skal søke i en enkelt underkatalog (for eksempel når du har en src/-katalog i repoet ditt), men hindre tilgang til resten av repoet.

info

Mens rootDir hovedsakelig brukes som token i andre konfigurasjonsvalg, bruker Jest roots internt for å lokalisere testfiler og kildefiler. Dette gjelder også ved søk etter manuelle mocks for moduler fra node_modules (__mocks__ må da ligge i en av roots-katalogene).

Standard er at roots har én oppføring: <rootDir>, men det finnes tilfeller der du ønsker flere rotkataloger i ett prosjekt, f.eks. roots: ["<rootDir>/src/", "<rootDir>/tests/"].

runtime [string]​

Standard: "jest-runtime"

Dette alternativet lar deg bruke en tilpasset runtime for å kjøre testfiler. En tilpasset runtime kan angis ved å oppgi stien til en runtime-implementasjon.

Runtime-modulen må eksportere en klasse som utvider Jests standard Runtime-klasse eller implementerer et kompatibelt grensesnitt med samme konstruktør-signatur og metoder.

advarsel

Å lage en tilpasset runtime er et avansert brukstilfelle. De fleste brukere trenger ikke tilpasse runtime. Vurder om brukstilfellet ditt kan løses bedre med tilpassede transformers, testmiljøer eller modulmocks.

Eksempel:

custom-runtime.js
const {default: Runtime} = require('jest-runtime');

class CustomRuntime extends Runtime {
  //...custom logic
}

module.exports = CustomRuntime;
custom-runtime.ts
import Runtime from 'jest-runtime';

export default class CustomRuntime extends Runtime {
  //...custom logic
}

Legg til den tilpassede runtime i Jest-konfigurasjonen din:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  runtime: './custom-runtime.js',
});

runner [string]​

Standard: "jest-runner"

Dette alternativet lar deg bruke en tilpasset testkjører i stedet for Jest sin standard. Eksempler på slike kjørende inkluderer:

info

Verdien for runner-egenskapen kan utelate jest-runner--prefikset i pakkenavnet.

For å skrive en test-runner, eksporter en klasse som aksepterer globalConfig i konstruktøren, og har en runTests-metode med signatur:

async function runTests(
  tests: Array<Test>,
  watcher: TestWatcher,
  onStart: OnTestStart,
  onResult: OnTestSuccess,
  onFailure: OnTestFailure,
  options: TestRunnerOptions,
): Promise<void>;

Hvis du trenger å begrense test-runneren din til kun å kjøre i serie i stedet for parallelt, bør klassen din ha egenskapen isSerial satt til true.

sandboxInjectedGlobals [array<string>]​

tips

Omdøpt fra extraGlobals i Jest 28.

Standard: undefined

Testfiler kjøres inne i en vm, noe som gjør kall til globale kontekstegenskaper (f.eks. Math) tregere. Med dette alternativet kan du spesifisere ekstra egenskaper som skal defineres inne i vm for raskere oppslag.

For eksempel, hvis testene dine ofte kaller Math, kan du sende den ved å sette sandboxInjectedGlobals.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  sandboxInjectedGlobals: ['Math'],
});
notat

Dette alternativet har ingen effekt hvis du bruker native ESM.

setupFiles [array]​

Standard: []

En liste over baner til moduler som kjører kode for å konfigurere eller sette opp testmiljøet. Hver setupFile vil kjøres én gang per testfil. Siden hver test kjører i sitt eget miljø, vil disse skriptene utføres i testmiljøet før setupFilesAfterEnv og før selve testkoden.

tips

Hvis oppsettskriptet ditt er en CJS-modul, kan den eksportere en asynkron funksjon. Jest vil kalle funksjonen og vente på resultatet. Dette kan være nyttig for å hente data asynkront. Hvis filen er en ESM-modul, kan du bruke top-level await for å oppnå samme resultat.

setupFilesAfterEnv [array]​

Standard: []

En liste over baner til moduler som kjører kode for å konfigurere eller sette opp testrammeverket før hver testfil i testgruppen utføres. Siden setupFiles utføres før testrammeverket installeres i miljøet, gir dette skriptet deg muligheten til å kjøre kode rett etter at testrammeverket er installert, men før selve testkoden.

Med andre ord er setupFilesAfterEnv-moduler ment for kode som gjentas i hver testfil. Ved å ha testrammeverket installert blir Jest globals, jest-objektet og expect tilgjengelig i modulene. For eksempel kan du legge til ekstra matchere fra jest-extended-biblioteket eller kalle setup og teardown-hooks:

setup-jest.js
const matchers = require('jest-extended');
expect.extend(matchers);

afterEach(() => {
  jest.useRealTimers();
});
jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  setupFilesAfterEnv: ['<rootDir>/setup-jest.js'],
});
tips

Hvis oppsettskriptet ditt er en CJS-modul, kan den eksportere en asynkron funksjon. Jest vil kalle funksjonen og vente på resultatet. Dette kan være nyttig for å hente data asynkront. Hvis filen er en ESM-modul, kan du bruke top-level await for å oppnå samme resultat.

showSeed [boolean]​

Standard: false

Tilsvarer flagget --showSeed for å skrive ut seeden i testrapportens sammendrag.

slowTestThreshold [number]​

Standardverdi: 5

Antall sekunder etter hvilken en test anses som treg og rapporteres som slik i resultatene.

snapshotFormat [object]​

Standard: {escapeString: false, printBasicPrototype: false}

Tillater overstyring av spesifikke formateringsalternativer for øyeblikksbilder dokumentert i pretty-format readme, med unntak av compareKeys og plugins. For eksempel ville denne konfigurasjonen fått øyeblikksbilsformatoren til ikke å skrive ut prefiks for "Object" og "Array":

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  snapshotFormat: {
    printBasicPrototype: false,
  },
});
some.test.js
test('does not show prototypes for object and array inline', () => {
  const object = {
    array: [{hello: 'Danger'}],
  };
  expect(object).toMatchInlineSnapshot(`
    {
      "array": [
        {
          "hello": "Danger",
        },
      ],
    }
  `);
});

snapshotResolver [string]​

Standard: undefined

Stien til en modul som kan løse test<->snapshot-sti. Dette konfigurasjonsalternativet lar deg tilpasse hvor Jest lagrer øyeblikksbilder på disken.

custom-resolver.js
module.exports = {
  // resolves from test to snapshot path
  resolveSnapshotPath: (testPath, snapshotExtension) =>
    testPath.replace('__tests__', '__snapshots__') + snapshotExtension,

  // resolves from snapshot to test path
  resolveTestPath: (snapshotFilePath, snapshotExtension) =>
    snapshotFilePath
      .replace('__snapshots__', '__tests__')
      .slice(0, -snapshotExtension.length),

  // Example test path, used for preflight consistency check of the implementation above
  testPathForConsistencyCheck: 'some/__tests__/example.test.js',
};

snapshotSerializers [array<string>]​

Standard: []

En liste over stier til øyeblikksbildserialisatormoduler som Jest skal bruke for øyeblikksbildetesting.

Jest har standardserialisatorer for innebygde JavaScript-typer, HTML-elementer (Jest 20.0.0+), ImmutableJS (Jest 20.0.0+) og React-elementer. Se øyeblikksbildtestopplæring for mer informasjon.

custom-serializer.js
module.exports = {
  serialize(val, config, indentation, depth, refs, printer) {
    return `Pretty foo: ${printer(val.foo, config, indentation, depth, refs)}`;
  },

  test(val) {
    return val && Object.prototype.hasOwnProperty.call(val, 'foo');
  },
};

printer er en funksjon som serialiserer en verdi ved hjelp av eksisterende plugins.

Legg til custom-serializer i Jest-konfigurasjonen din:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  snapshotSerializers: ['path/to/custom-serializer.js'],
});

Til slutt vil testene se slik ut:

test(() => {
  const bar = {
    foo: {
      x: 1,
      y: 2,
    },
  };

  expect(bar).toMatchSnapshot();
});

Vist øyeblikksbilde:

Pretty foo: Object {
  "x": 1,
  "y": 2,
}
tips

For å gjøre en avhengighet eksplisitt i stedet for implisitt, kan du bruke expect.addSnapshotSerializer for å legge til en modul for en enkelt testfil i stedet for å legge til stien i snapshotSerializers i Jest-konfigurasjonen.

Mer om serialisator-API finner du her.

testEnvironment [string]​

Standard: "node"

Testmiljøet som skal brukes for testing. Standardmiljøet i Jest er et Node.js-miljø. Hvis du bygger en webapp, kan du bruke et nettleserlignende miljø via jsdom i stedet.

Ved å legge til en @jest-environment-dokblokk på toppen av filen kan du spesifisere et annet miljø som skal brukes for alle tester i den filen:

/**
 * @jest-environment jsdom
 */

test('use jsdom in this test file', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Du kan opprette din egen modul som skal brukes til å sette opp testmiljøet. Modulen må eksportere en klasse med metodene setup, teardown og getVmContext. Du kan også sende variabler fra denne modulen til testgruppene dine ved å tilordne dem til this.global-objektet – dette vil gjøre dem tilgjengelige i testgruppene dine som globale variabler. Konstruktøren får globalConfig og projectConfig som første argument, og testEnvironmentContext som andre.

Klassen kan eventuelt eksponere en asynkron handleTestEvent-metode for å koble seg til hendelser utløst av jest-circus. Normalt ville jest-circus testkjøren pause til en promise returnert fra handleTestEvent er oppfylt, unntatt for følgende hendelser: start_describe_definition, finish_describe_definition, add_hook, add_test eller error (for oppdatert liste se SyncEvent type i type-definisjonene). Dette skyldes bakoverkompabilitet og process.on('unhandledRejection', callback)-signaturen, men utgjør vanligvis ikke et problem for de fleste brukstilfeller.

Eventuelle docblock-pragmas i testfiler vil bli sendt til miljøkonstruktøren og kan brukes for testspesifikk konfigurasjon. Hvis pragmaen ikke har en verdi, vil den være til stede i objektet med en tom streng som verdi. Hvis pragmaen ikke er til stede, vil den ikke finnes i objektet.

For å bruke denne klassen som ditt egendefinerte miljø, referer til den med dens fulle sti i prosjektet. For eksempel, hvis klassen din er lagret i my-custom-environment.js i en undermappe, kan annotasjonen se slik ut:

/**
 * @jest-environment ./src/test/my-custom-environment
 */
info

TestEnvironment er sandboxet. Hver testsuite vil utløse oppsett/nedrydding i sitt eget TestEnvironment.

Eksempel:

// my-custom-environment
const NodeEnvironment = require('jest-environment-node').TestEnvironment;

class CustomEnvironment extends NodeEnvironment {
  constructor(config, context) {
    super(config, context);
    console.log(config.globalConfig);
    console.log(config.projectConfig);
    this.testPath = context.testPath;
    this.docblockPragmas = context.docblockPragmas;
  }

  async setup() {
    await super.setup();
    await someSetupTasks(this.testPath);
    this.global.someGlobalObject = createGlobalObject();

    // Will trigger if docblock contains @my-custom-pragma my-pragma-value
    if (this.docblockPragmas['my-custom-pragma'] === 'my-pragma-value') {
      // ...
    }
  }

  async teardown() {
    this.global.someGlobalObject = destroyGlobalObject();
    await someTeardownTasks();
    await super.teardown();
  }

  getVmContext() {
    return super.getVmContext();
  }

  async handleTestEvent(event, state) {
    if (event.name === 'test_start') {
      // ...
    }
  }
}

module.exports = CustomEnvironment;
// my-test-suite
/**
 * @jest-environment ./my-custom-environment
 */
let someGlobalObject;

beforeAll(() => {
  someGlobalObject = globalThis.someGlobalObject;
});

testEnvironmentOptions [Object]​

Standard: {}

Testmiljø-alternativer som vil bli sendt til testEnvironment. Relevante alternativer avhenger av miljøet.

For eksempel kan du overstyre alternativer sendt til jsdom:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  testEnvironment: 'jsdom',
  testEnvironmentOptions: {
    html: '<html lang="zh-cmn-Hant"></html>',
    url: 'https://jestjs.io/',
    userAgent: 'Agent/007',
  },
});

Både jest-environment-jsdom og jest-environment-node tillater spesifisering av customExportConditions, som lar deg kontrollere hvilke versjoner av et bibliotek som lastes fra exports i package.json. jest-environment-jsdom standardiserer til ['browser']. jest-environment-node standardiserer til ['node', 'node-addons'].

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  testEnvironment: 'jsdom',
  testEnvironmentOptions: {
    customExportConditions: ['react-native'],
  },
});

Disse alternativene kan også sendes via docblock, liknende testEnvironment. Strengen med alternativer må kunne tolkes av JSON.parse:

/**
 * @jest-environment jsdom
 * @jest-environment-options {"url": "https://jestjs.io/"}
 */

test('use jsdom and set the URL in this test file', () => {
  expect(window.location.href).toBe('https://jestjs.io/');
});

testFailureExitCode [number]​

Standard: 1

Avslutningskoden Jest returnerer ved testfeil.

info

Dette endrer ikke avslutningskoden ved Jest-feil (f.eks. ugyldig konfigurasjon).

testMatch [array<string>]​

(standard: [ "**/__tests__/**/*.?([mc])[jt]s?(x)", "**/?(*.)+(spec|test).?([mc])[jt]s?(x)" ])

Glob-mønstrene Jest bruker for å oppdage testfiler. Standard søker den etter .js-, .jsx-, .ts- og .tsx-filer i __tests__-mapper, samt filer med suffiksene .test eller .spec (f.eks. Component.test.js eller Component.spec.js). Den vil også finne filer som heter test.js eller spec.js.

Se micromatch-pakken for detaljer om tilgjengelige mønstre.

Se også testRegex [string | array<string>], men merk at du ikke kan spesifisere begge alternativene samtidig.

tips

Hvert glob-mønster brukes i rekkefølgen de er spesifisert i konfigurasjonen. For eksempel vil ["!**/__fixtures__/**", "**/__tests__/**/*.js"] ikke ekskludere __fixtures__ fordi negasjonen overskrives av det andre mønsteret. For at negert glob skal fungere i dette eksempelet må det komme etter **/__tests__/**/*.js.

testPathIgnorePatterns [array<string>]​

Default: ["/node_modules/"]

En matris med regulære uttrykk som sammenlignes med alle teststier før testene kjøres. Hvis teststien samsvarer med noen av mønstrene, vil den bli hoppet over.

Disse mønstrene sammenlignes med hele stien. Bruk strengtokenet <rootDir> for å inkludere stien til prosjektets rotmappe for å forhindre at den ved et uhell ignorerer alle filene dine i forskjellige miljøer som kan ha ulike rotkataloger. Eksempel: ["<rootDir>/build/", "<rootDir>/node_modules/"].

testRegex [string | array<string>]​

Default: (/__tests__/.*|(\\.|/)(test|spec))\\.[mc]?[jt]sx?$

Mønsteret eller mønstrene Jest bruker for å oppdage testfiler. Som standard ser den etter .js, .jsx, .ts og .tsx-filer i __tests__-mapper, samt alle filer med suffikset .test eller .spec (f.eks. Component.test.js eller Component.spec.js). Den finner også filer som heter test.js eller spec.js. Se også testMatch [array<string>], men merk at du ikke kan spesifisere begge alternativene samtidig.

Følgende er en visualisering av standard regex:

├── __tests__
│   └── component.spec.js # test
│   └── anything # test
├── package.json # not test
├── foo.test.js # test
├── bar.spec.jsx # test
└── component.js # not test
info

testRegex vil forsøke å oppdage testfiler ved hjelp av den absolutte filstien, så hvis du har en mappe med et navn som samsvarer med mønsteret, vil alle filene i den kjøres som tester.

testResultsProcessor [string]​

Standard: undefined

Dette alternativet lar deg bruke en egendefinert resultatprosessor. Denne prosessoren må være en node-modul som eksporterer en funksjon som forventer et objekt med følgende struktur som første argument og returnerer det:

{
  "success": boolean,
  "startTime": epoch,
  "numTotalTestSuites": number,
  "numPassedTestSuites": number,
  "numFailedTestSuites": number,
  "numRuntimeErrorTestSuites": number,
  "numTotalTests": number,
  "numPassedTests": number,
  "numFailedTests": number,
  "numPendingTests": number,
  "numTodoTests": number,
  "openHandles": Array<Error>,
  "testResults": [{
    "numFailingTests": number,
    "numPassingTests": number,
    "numPendingTests": number,
    "testResults": [{
      "title": string (message in it block),
      "status": "failed" | "pending" | "passed",
      "ancestorTitles": [string (message in describe blocks)],
      "failureMessages": [string],
      "numPassingAsserts": number,
      "location": {
        "column": number,
        "line": number
      },
      "duration": number | null,
      "startAt": epoch | null
    },
    ...
    ],
    "perfStats": {
      "end": epoch,
      "loadTestEnvironmentEnd": epoch,
      "loadTestEnvironmentStart": epoch,
      "runtime": number,
      "setupAfterEnvEnd": epoch,
      "setupAfterEnvStart": epoch,
      "setupFilesEnd": epoch,
      "setupFilesStart": epoch,
      "slow": boolean,
      "start": epoch
    },
    "testFilePath": absolute path to test file,
    "coverage": {}
  },
  "testExecError:" (exists if there was a top-level failure) {
    "message": string
    "stack": string
  }
  ...
  ]
}

testResultsProcessor og reporters er veldig like. En forskjell er at en testresultatprosessor kun kalles etter at alle testene er ferdige. Mens en reporter kan motta testresultater etter at enkelttester og/eller testsuiter er fullført.

testRunner [string]​

Default: jest-circus/runner

Dette alternativet lar deg bruke en egendefinert testkjører. Standard er jest-circus. En egendefinert testkjører kan angis ved å oppgi stien til en implementasjon av testkjøreren.

Testkjørermodulen må eksportere en funksjon med følgende signatur:

function testRunner(
  globalConfig: GlobalConfig,
  config: ProjectConfig,
  environment: Environment,
  runtime: Runtime,
  testPath: string,
): Promise<TestResult>;

Et eksempel på en slik funksjon finner du i vår standard jasmine2 testkjører-pakke.

testSequencer [string]​

Default: @jest/test-sequencer

Dette alternativet lar deg bruke en egendefinert sekvenser i stedet for Jests standard.

tips

Både sort og shard kan valgfritt returnere et Promise.

For eksempel kan du sortere teststier alfabetisk:

custom-sequencer.js
const Sequencer = require('@jest/test-sequencer').default;

class CustomSequencer extends Sequencer {
  /**
   * Select tests for shard requested via --shard=shardIndex/shardCount
   * Sharding is applied before sorting
   */
  shard(tests, {shardIndex, shardCount}) {
    const shardSize = Math.ceil(tests.length / shardCount);
    const shardStart = shardSize * (shardIndex - 1);
    const shardEnd = shardSize * shardIndex;

    return [...tests]
      .sort((a, b) => (a.path > b.path ? 1 : -1))
      .slice(shardStart, shardEnd);
  }

  /**
   * Sort test to determine order of execution
   * Sorting is applied after sharding
   */
  sort(tests) {
    // Test structure information
    // https://github.com/jestjs/jest/blob/6b8b1404a1d9254e7d5d90a8934087a9c9899dab/packages/jest-runner/src/types.ts#L17-L21
    const copyTests = [...tests];
    return copyTests.sort((testA, testB) => (testA.path > testB.path ? 1 : -1));
  }
}

module.exports = CustomSequencer;

Legg til custom-sequencer i Jest-konfigurasjonen din:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  testSequencer: 'path/to/custom-sequencer.js',
});

testTimeout [number]​

Default: 5000

Standard timeout for en test i millisekunder.

transform [object<string, pathToTransformer | [pathToTransformer, object]>]​

Default: {"\\.[jt]sx?$": "babel-jest"}

En mapping fra regulære uttrykk til stier til transformatorer. Du kan også sende med en tuppel med konfigurasjonsalternativer som andre argument: {filePattern: ['path-to-transformer', {options}]}. For eksempel, slik kan du konfigurere babel-jest for ikke-standard oppførsel: {'\\.js$': ['babel-jest', {rootMode: 'upward'}]}.

Jest kjører koden i prosjektet ditt som JavaScript, så en transformator er nødvendig hvis du bruker syntaks som ikke støttes direkte av Node (som JSX, TypeScript eller Vue-maler). Som standard bruker Jest babel-jest-transformatoren, som laster Babel-konfigurasjonen din og transformerer alle filer som samsvarer med regulært uttrykk /\.[jt]sx?$/ (dvs. alle .js-, .jsx-, .ts- eller .tsx-filer). I tillegg vil babel-jest injisere Babel-pluginen som er nødvendig for mock-heving beskrevet i ES Module mocking.

Se delen om Kodetransformering for flere detaljer og instruksjoner om å bygge din egen transformator.

tips

Husk at en transformer kun kjører én gang per fil med mindre fila er endret.

Husk å inkludere standard babel-jest-transformer eksplisitt hvis du ønsker å bruke den sammen med tilleggskodepreprosessorer:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  transform: {
    '\\.[jt]sx?$': 'babel-jest',
    '\\.css$': 'some-css-transformer',
  },
});

transformIgnorePatterns [array<string>]​

Standard: ["/node_modules/", "\\.pnp\\.[^\\\/]+$"]

En array med regex-mønstre som matches mot alle kildefilstier før transformering. Hvis filstien matcher noe av mønsteret, vil den ikke bli transformert.

Mønstre som overlapper hverandre kan føre til at filer du forventet skulle transformeres blir ignorert. For eksempel:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  transformIgnorePatterns: ['/node_modules/(?!(foo|bar)/)', '/bar/'],
});

Det første mønsteret vil matche (og dermed ikke transformere) filer i /node_modules bortsett fra dem i /node_modules/foo/ og /node_modules/bar/. Det andre mønsteret vil matche (og ignorere) filer i stier som inneholder /bar/. Sammen vil filer i /node_modules/bar/ ikke bli transformert fordi de matcher det andre mønsteret, selv om de var unntatt fra det første.

I noen tilfeller (spesielt i React Native- eller TypeScript-prosjekter) publiseres tredjepartsmoduler som ukompilert kode. Siden alle filer i node_modules ikke transformeres som standard, vil Jest ikke forstå koden i disse modulene og gi syntaksfeil. For å løse dette kan du bruke transformIgnorePatterns for å tillate transformering av slike moduler. Du finner et godt eksempel på dette i React Native-guiden.

Disse mønstrene matches mot hele stien. Bruk <rootDir>-strengen for å inkludere prosjektrotkatalogen og unngå utilsiktet ignorering av filer på tvers av miljøer med ulike rotkataloger.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  transformIgnorePatterns: [
    '<rootDir>/bower_components/',
    '<rootDir>/node_modules/',
  ],
});
tips

Hvis du bruker pnpm og trenger å konvertere noen pakker under node_modules, må du merke deg at pakkene i denne mappen (f.eks. node_modules/package-a/) er symlinket til stien under .pnpm (f.eks. node_modules/.pnpm/package-a@x.x.x/node_modules/package-a/). Derfor vil direkte bruk av <rootDir>/node_modules/(?!(package-a|@scope/pkg-b)/) ikke bli gjenkjent. I stedet bør du bruke:

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  transformIgnorePatterns: [
    '<rootDir>/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)',
    /* if config file is under '~/packages/lib-a/' */
    `${path.join(
      __dirname,
      '../..',
    )}/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)`,
    /* or using relative pattern to match the second 'node_modules/' in 'node_modules/.pnpm/@scope+pkg-b@x.x.x/node_modules/@scope/pkg-b/' */
    'node_modules/(?!.pnpm|package-a|@scope/pkg-b)',
  ],
});

Vær oppmerksom på at mappenavnet til pnpm under .pnpm består av pakkenavnet pluss @ og versjonsnummer. Derfor vil bruk av / ikke bli gjenkjent, mens @ vil fungere.

unmockedModulePathPatterns [array<string>]​

Standard: []

En array med regexp-mønstre som matches mot alle moduler før modullasteren automatisk returnerer en mock for dem. Hvis en moduls bane matcher noe av mønsteret i denne listen, vil den ikke bli automocket av modullasteren.

Dette er nyttig for vanlige "verktøymoduler" som nesten alltid brukes som implementasjonsdetaljer (som underscore, lodash, etc). Best praksis er å holde denne listen så liten som mulig og alltid bruke eksplisitte jest.mock()/jest.unmock()-kall i individuelle tester. Eksplisitt testoppsett gjør det enklere for andre lesere å forstå testens kjøremiljø.

Denne innstillingen kan overstyres i individuelle tester ved å eksplisitt kalle jest.mock() på toppen av testfilen.

verbose [boolean]​

Standard: false eller true hvis det kun er én testfil å kjøre

Angir om hver enkelt test skal rapporteres under kjøring. Alle feil vil fortsatt vises nederst etter utførelse.

waitForUnhandledRejections [boolean]​

Gir én hendelsessyklus for å håndtere rejectionHandled, uncaughtException eller unhandledRejection.

Uten dette flagget kan Jest rapportere falske positive feil (f.eks. rapportere håndterte avvisninger) eller ikke rapportere faktisk uhåndterte avvisninger (eller rapportere dem for feil testtilfelle).

Denne opsjonen kan legge til merkbar overhead for raske testsuiter.

watchPathIgnorePatterns [array<string>]​

Standard: []

En array med regexp-mønstre som matches mot alle kildefilbaner før tester kjøres på nytt i overvåkingsmodus. Hvis filbanen matcher noe av mønsteret, vil oppdateringer ikke utløse ny testkjøring.

Disse mønstrene samsvarer med hele stien. Bruk strengtokenet <rootDir> for å inkludere stien til prosjektets rotmappe for å forhindre at den ved et uhell utelukker alle filene dine i forskjellige miljøer som kan ha ulike rotmapper. Eksempel: ["<rootDir>/node_modules/"].

Selv om ingenting er spesifisert her, vil overvåkeren ignorere endringer i versjonskontrollmapper (.git, .hg, .sl). Andre skjulte filer og mapper, dvs. de som begynner med et punktum (.), overvåkes som standard. Husk å escape punktumet når du legger dem til i watchPathIgnorePatterns da det er et spesielt RegExp-tegn.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  watchPathIgnorePatterns: ['<rootDir>/\\.tmp/', '<rootDir>/bar/'],
});

watchPlugins [array<string | [string, Object]>]​

Standard: []

Dette alternativet lar deg bruke egendefinerte overvåkningsplugins. Les mer om overvåkningsplugins her.

Eksempler på overvåkningsplugins inkluderer:

info

Verdiene i watchPlugins-egenskapen kan utelate jest-watch- prefikset i pakkenavnet.

watchman [boolean]​

Standard: true

Om watchman skal brukes for filkartlegging.

workerIdleMemoryLimit [number|string]​

Standard: undefined

Spesifiserer minnegrensen for arbeidere før de resirkuleres og er primært en løsning for dette problemet;

Etter at en arbeider har utført en test, sjekkes minnebruken. Hvis den overskrider spesifisert verdi avsluttes arbeideren og startes på nytt. Grensen kan spesifiseres på flere måter, og uansett resultat brukes Math.floor for å konvertere til heltallsverdi:

  • <= 1 - Verdien antas å være en prosentandel av systemminnet. F.eks. vil 0,5 sette minnegrensen til halvparten av totalt systemminne

  • \> 1 - Antas å være en fast byteverdi. På grunn av forrige regel, hvis du ønsker 1 byte (usannsynlig), kan du bruke 1.1.

  • Med enheter

    • 50% - Som ovenfor, en prosentandel av totalt systemminne
    • 100KB, 65MB, osv. - Med enheter for å angi fast minnegrense
      • K / KB - Kilobytes (x1000)
      • KiB - Kibibytes (x1024)
      • M / MB - Megabytes
      • MiB - Mebibytes
      • G / GB - Gigabytes
      • GiB - Gibibytes
advarsel

Prosentbasert minnegrense fungerer ikke på Linux CircleCI-arbeidere på grunn av feilrapportert systemminne.

jest.config.js
const {defineConfig} = require('jest');

module.exports = defineConfig({
  workerIdleMemoryLimit: 0.2,
});

// [string]​

Dette alternativet tillater kommentarer i package.json. Inkluder kommentarteksten som verdien til denne nøkkelen:

package.json
{
  "name": "my-project",
  "jest": {
    "//": "Comment goes here",
    "verbose": true
  }
}

workerThreads​

Standard: false

Angir om worker threads skal brukes for parallellisering. Child processes brukes som standard.

Bruk av worker threads kan bidra til å forbedre ytelsen.

advarsel

Dette er en eksperimentell funksjon. Husk at worker threads bruker structured clone i stedet for JSON.stringify() for å serialisere meldinger. Dette betyr at innebygde JavaScript-objekter som BigInt, Map eller Set vil bli serialisert riktig. Imidlertid vil ekstra egenskaper satt på Error, Map eller Set ikke bli ført videre gjennom serialiseringstrinnet. For mer informasjon, se artikkelen om structured clone.