Zum Hauptinhalt springen
Version: 29.7

Jest konfigurieren

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Die Philosophie von Jest ist es, standardmäßig hervorragend zu funktionieren, aber manchmal benötigt man einfach mehr Konfigurationsmöglichkeiten.

Es wird empfohlen, die Konfiguration in einer dedizierten JavaScript-, TypeScript- oder JSON-Datei zu definieren. Die Datei wird automatisch erkannt, wenn sie jest.config.js|ts|mjs|cjs|json heißt. Du kannst das Flag --config verwenden, um einen expliziten Pfad zur Datei anzugeben.

Hinweis

Beachte, dass das resultierende Konfigurationsobjekt immer JSON-serialisierbar sein muss.

Die Konfigurationsdatei sollte einfach ein Objekt exportieren:

/** @type {import('jest').Config} */
const config = {
  verbose: true,
};

module.exports = config;

Oder eine Funktion, die ein Objekt zurückgibt:

/** @returns {Promise<import('jest').Config>} */
module.exports = async () => {
  return {
    verbose: true,
  };
};
Tipp

Zum Lesen von TypeScript-Konfigurationsdateien benötigt Jest ts-node. Stelle sicher, dass es in deinem Projekt installiert ist.

Die Konfiguration kann auch als einfaches Objekt in einer JSON-Datei gespeichert werden:

jest.config.json
{
  "bail": 1,
  "verbose": true
}

Alternativ kann Jests Konfiguration über den "jest"-Schlüssel in der package.json deines Projekts definiert werden:

package.json
{
  "name": "my-project",
  "jest": {
    "verbose": true
  }
}

Optionen​

Hinweis

Du kannst Jests Standardwerte aus jest-config abrufen, um sie bei Bedarf zu erweitern:

const {defaults} = require('jest-config');

/** @type {import('jest').Config} */
const config = {
  moduleFileExtensions: [...defaults.moduleFileExtensions, 'mts', 'cts'],
};

module.exports = config;

Referenz​

automock [boolean]​

Standard: false

Diese Option weist Jest an, alle importierten Module in deinen Tests automatisch zu mocken. Alle in Tests verwendeten Module erhalten eine Ersetzungsimplementierung, wobei die API-Oberfläche erhalten bleibt.

Beispiel:

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();
});
Hinweis

Node-Module werden automatisch gemockt, wenn ein manueller Mock vorhanden ist (z.B. __mocks__/lodash.js). Mehr Informationen hier.

Node.js-Kernmodule wie fs werden standardmäßig nicht gemockt. Sie können explizit gemockt werden, z.B. mit jest.mock('fs').

bail [number | boolean]​

Standard: 0

Standardmäßig führt Jest alle Tests aus und gibt alle Fehler nach Abschluss in der Konsole aus. Die Bail-Option kann verwendet werden, um Jest nach n Fehlern anzuhalten. Das Setzen von bail auf true ist dasselbe wie das Setzen auf 1.

cacheDirectory [string]​

Standard: "/tmp/<path>"

Das Verzeichnis, in dem Jest seine zwischengespeicherten Abhängigkeitsinformationen speichern soll.

Jest versucht, Ihre Abhängigkeitsstruktur einmalig (im Voraus) zu scannen und zwischenzuspeichern, um den Dateisystem-Overhead während der Testausführung zu reduzieren. Diese Option ermöglicht es, den Speicherort für diese Cache-Daten auf dem Datenträger anzupassen.

clearMocks [boolean]​

Standard: false

Löscht automatisch Mock-Aufrufe, Instanzen, Kontexte und Ergebnisse vor jedem Test. Entspricht dem Aufruf von jest.clearAllMocks() vor jedem Test. Entfernt keine Mock-Implementierungen, die möglicherweise bereitgestellt wurden.

collectCoverage [boolean]​

Standard: false

Gibt an, ob während der Testausführung Coverage-Informationen gesammelt werden sollen. Da dies alle ausgeführten Dateien mit Coverage-Erfassungsanweisungen erweitert, kann es die Testgeschwindigkeit erheblich reduzieren.

Jest bietet zwei Coverage-Provider: babel (Standard) und v8. Details unter coverageProvider.

Hinweis

Die Coverage-Provider babel und v8 verwenden Kommentare /* istanbul ignore next */ bzw. /* c8 ignore next */, um Zeilen von Coverage-Berichten auszuschließen. Weitere Informationen: istanbuljs-Dokumentation und c8-Dokumentation.

collectCoverageFrom [array]​

Standard: undefined

Ein Array von Glob-Mustern, die Dateien definieren, für die Coverage-Informationen gesammelt werden sollen. Wenn eine Datei einem Muster entspricht, wird ihre Coverage erfasst – selbst wenn keine Tests existieren oder sie im Testsuite nicht eingebunden wird.

/** @type {import('jest').Config} */
const config = {
  collectCoverageFrom: [
    '**/*.{js,jsx}',
    '!**/node_modules/**',
    '!**/vendor/**',
  ],
};

module.exports = config;

Erfasst Coverage für alle Dateien im rootDir des Projekts, außer **/node_modules/** oder **/vendor/**.

Tipp

Glob-Muster werden in der konfigurierten Reihenfolge verarbeitet. Beispiel: ["!**/__tests__/**", "**/*.js"] schließt __tests__ NICHT aus, da das Negationsmuster vom zweiten Muster überschrieben wird. Für korrekte Negation muss das Negationsmuster nach **/*.js stehen.

Hinweis

Diese Option erfordert, dass collectCoverage auf true gesetzt ist oder dass Jest mit --coverage aufgerufen wird.

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

Das Verzeichnis, in dem Jest seine Coverage-Dateien ausgeben soll.

coveragePathIgnorePatterns [array<string>]​

Standard: ["/node_modules/"]

Ein Array von Regex-Mustern, die gegen Dateipfade geprüft werden. Bei Übereinstimmung wird die Coverage-Erfassung übersprungen.

Diese Muster werden mit dem vollständigen Pfad abgeglichen. Verwenden Sie den <rootDir>-Platzhalter, um den Pfad zum Projektstammverzeichnis einzubeziehen. Dies verhindert, dass versehentlich Dateien in verschiedenen Umgebungen mit unterschiedlichen Stammverzeichnissen ignoriert werden. Beispiel: ["<rootDir>/build/", "<rootDir>/node_modules/"].

coverageProvider [string]​

Legt den Provider fest, der zur Instrumentierung von Code für die Abdeckungsanalyse verwendet wird. Zulässige Werte sind babel (Standard) oder v8.

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

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

Eine Liste von Reporter-Namen, die Jest für die Erstellung von Coverage-Berichten verwendet. Jeder Istanbul Reporter kann genutzt werden.

Tipp

Durch Setzen dieser Option werden die Standardwerte überschrieben. Füge "text" oder "text-summary" hinzu, um eine Coverage-Zusammenfassung in der Konsolenausgabe zu sehen.

Zusätzliche Optionen können über die Tupel-Form übergeben werden. Beispielsweise kannst du Coverage-Berichtszeilen für vollständig abgedeckte Dateien ausblenden:

/** @type {import('jest').Config} */
const config = {
  coverageReporters: ['clover', 'json', 'lcov', ['text', {skipFull: true}]],
};

module.exports = config;

Weitere Informationen zur Struktur des Optionsobjekts findest du im Typ CoverageReporterWithOptions in den Typdefinitionen.

coverageThreshold [object]​

Standard: undefined

Konfiguriert Mindestanforderungen für Coverage-Ergebnisse. Schwellenwerte können als global, als Glob oder als Datei-/Verzeichnispfad definiert werden. Bei Nichterreichen scheitert Jest. Positive Werte definieren Mindestprozentsätze, negative Werte maximale erlaubte ungedeckte Entitäten.

Beispiel: Mit dieser Konfiguration scheitert Jest bei weniger als 80% Branch-, Line- und Function-Coverage oder mehr als 10 ungedeckten Statements:

/** @type {import('jest').Config} */
const config = {
  coverageThreshold: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: -10,
    },
  },
};

module.exports = config;

Bei Kombination von global mit Glob/Path-Angaben werden deren Coverage-Daten vom Gesamtergebnis abgezogen. Schwellenwerte für Globs gelten für alle passenden Dateien. Nicht gefundene Pfade erzeugen Fehler.

Beispielkonfiguration:

/** @type {import('jest').Config} */
const config = {
  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,
    },
  },
};

module.exports = config;

Jest scheitert, wenn:

  • Das Verzeichnis ./src/components weniger als 40% Branch- oder Statement-Coverage hat.

  • Eine Datei des ./src/reducers/**/*.js-Globs weniger als 90% Statement-Coverage hat.

  • Die Datei ./src/api/very-important-module.js weniger als 100% Coverage hat.

  • Die restlichen Dateien insgesamt weniger als 50% Coverage haben (global).

dependencyExtractor [string]​

Standard: undefined

Ermöglicht die Verwendung eines benutzerdefinierten Dependency Extractors. Muss ein Node-Modul sein, das ein Objekt mit einer extract-Funktion exportiert. Beispiel:

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');
  },
};

Die extract-Funktion muss ein Iterable (Array, Set, etc.) mit den im Code gefundenen Abhängigkeiten zurückgeben.

Das Modul kann auch eine getCacheKey-Funktion enthalten, um Cache-Keys zu generieren und veraltete Artefakte zu verwerfen.

displayName [string, object]​

Standardwert: undefined

Ermöglicht die Anzeige eines Labels neben laufenden Tests. Besonders nützlich in Multi-Projekt-Repositories, um Tests zuzuordnen.

/** @type {import('jest').Config} */
const config = {
  displayName: 'CLIENT',
};

module.exports = config;

Alternativ kann ein Objekt mit name und color übergeben werden. Dies erlaubt individuelle Hintergrundfarben für displayName. String-Werte sind standardmäßig weiß. Jest nutzt chalk, unterstützt also alle validen Farboptionen von chalk.

/** @type {import('jest').Config} */
const config = {
  displayName: {
    name: 'CLIENT',
    color: 'blue',
  },
};

module.exports = config;

errorOnDeprecated [boolean]​

Standard: false

Lässt Aufrufe veralteter APIs mit hilfreichen Fehlermeldungen scheitern. Erleichtert Upgrades.

extensionsToTreatAsEsm [array<string>]​

Standard: []

Jest führt .mjs- und .js-Dateien aus, deren nächstgelegene package.json ein type-Feld mit dem Wert module hat, als ECMAScript-Module. Falls Sie andere Dateien haben, die mit nativen ESM laufen sollen, müssen Sie deren Dateiendung hier angeben.

/** @type {import('jest').Config} */
const config = {
  extensionsToTreatAsEsm: ['.ts'],
};

module.exports = config;
Vorsicht

Jests ESM-Unterstützung ist noch experimentell. Weitere Details finden Sie in der Dokumentation.

fakeTimers [object]​

Standard: {}

Künstliche Timer sind nützlich, wenn Code lange Timeouts setzt, die in Tests nicht abgewartet werden sollen. Weitere Details im Leitfaden zu künstlichen Timern und der API-Dokumentation.

Diese Option liefert die Standardkonfiguration für künstliche Timer in allen Tests. Der Aufruf von jest.useFakeTimers() in einer Testdatei verwendet diese Einstellungen oder überschreibt sie bei Übergabe eines Konfigurationsobjekts. Beispielsweise können Sie Jest anweisen, die Originalimplementierung von process.nextTick() beizubehalten und das Limit rekursiver Timer anzupassen:

/** @type {import('jest').Config} */
const config = {
  fakeTimers: {
    doNotFake: ['nextTick'],
    timerLimit: 1000,
  },
};

module.exports = config;
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});
  // ...
});
Tipp

Statt jest.useFakeTimers() in jede Testdatei einzufügen, können Sie künstliche Timer global für alle Tests in Ihrer Jest-Konfiguration aktivieren:

/** @type {import('jest').Config} */
const config = {
  fakeTimers: {
    enableGlobally: true,
  },
};

module.exports = config;

Konfigurationsoptionen:

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;
};
Legacy Fake Timers

Falls erforderlich, können Sie die Legacy-Implementierung künstlicher Timer verwenden. So aktivieren Sie sie global (zusätzliche Optionen werden nicht unterstützt):

/** @type {import('jest').Config} */
const config = {
  fakeTimers: {
    enableGlobally: true,
    legacyFakeTimers: true,
  },
};

module.exports = config;

forceCoverageMatch [array<string>]​

Standard: ['']

Testdateien werden normalerweise von der Code-Coverage-Erfassung ausgeschlossen. Mit dieser Option können Sie dies überschreiben und ansonsten ignorierte Dateien einbeziehen.

Beispiel: Wenn Sie Tests in Quelldateien mit der Endung .t.js haben:

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);
  });
}

Können Sie deren Coverage mit forceCoverageMatch erfassen:

/** @type {import('jest').Config} */
const config = {
  forceCoverageMatch: ['**/*.t.js'],
};

module.exports = config;

globals [object]​

Standard: {}

Ein Satz globaler Variablen, die in allen Testumgebungen verfügbar sein müssen.

Beispiel: So erstellen Sie eine globale Variable __DEV__ mit dem Wert true für alle Testumgebungen:

/** @type {import('jest').Config} */
const config = {
  globals: {
    __DEV__: true,
  },
};

module.exports = config;
Hinweis

Wenn Sie hier einen globalen Referenzwert (wie ein Objekt oder Array) angeben und Code diesen während eines Tests verändert, wird diese Änderung nicht über Testläufe in anderen Dateien hinweg beibehalten. Zudem muss das globals-Objekt JSON-serialisierbar sein – globale Funktionen können hier nicht definiert werden. Verwenden Sie hierfür setupFiles.

globalSetup [string]​

Standard: undefined

Diese Option ermöglicht die Verwendung eines benutzerdefinierten globalen Setup-Moduls, das eine Funktion exportieren muss (synchron oder asynchron). Die Funktion wird einmal vor allen Testsuites ausgelöst und erhält zwei Argumente: Jests globalConfig und projectConfig.

Hinweis

Ein globales Setup-Modul, das in einem Projekt konfiguriert ist (mit Multi-Project-Runner), wird nur ausgelöst, wenn mindestens ein Test aus diesem Projekt ausgeführt wird.

Globale Variablen, die über globalSetup definiert werden, sind ausschließlich in globalTeardown lesbar. Sie können diese Globals nicht in Ihren Testsuites abrufen.

Während Code-Transformation auf die verlinkte Setup-Datei angewendet wird, transformiert Jest keinen Code in node_modules. Dies ist notwendig, da die eigentlichen Transformer (z.B. babel oder typescript) geladen werden müssen, um die Transformation durchzuführen.

setup.js
module.exports = async function (globalConfig, projectConfig) {
  console.log(globalConfig.testPathPattern);
  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.testPathPattern);
  console.log(projectConfig.cache);

  await globalThis.__MONGOD__.stop();
};

globalTeardown [string]​

Standard: undefined

Diese Option ermöglicht die Verwendung eines benutzerdefinierten globalen Teardown-Moduls, das eine Funktion exportieren muss (synchron oder asynchron). Die Funktion wird einmal nach allen Testsuites ausgelöst und erhält zwei Argumente: Jests globalConfig und projectConfig.

Hinweis

Ein globales Teardown-Modul, das in einem Projekt konfiguriert ist (mit Multi-Project-Runner), wird nur ausgelöst, wenn mindestens ein Test aus diesem Projekt ausgeführt wird.

Die gleiche Einschränkung bezüglich der Transformation von node_modules wie bei globalSetup gilt auch für globalTeardown.

haste [object]​

Standard: undefined

Hiermit wird das Verhalten von jest-haste-map, Jests internem Datei-Crawler/Cache-System, konfiguriert. Folgende Optionen werden unterstützt:

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

Fügt Jests Globals (expect, test, describe, beforeEach etc.) in die globale Umgebung ein. Bei false müssen Sie diese aus @jest/globals importieren, z.B.:

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

jest.useFakeTimers();

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

Diese Option wird nur mit dem standardmäßigen jest-circus-Testrunner unterstützt.

maxConcurrency [number]​

Standard: 5

Begrenzt die Anzahl der Tests, die gleichzeitig mit test.concurrent ausgeführt werden dürfen. Tests über diesem Limit werden in eine Warteschlange gestellt und ausgeführt, sobald ein Slot frei wird.

maxWorkers [number | string]​

Legt die maximale Anzahl von Workern fest, die der Worker-Pool für das Ausführen von Tests erzeugt. Im Einzelausführungsmodus entspricht dies standardmäßig der Anzahl der verfügbaren CPU-Kerne minus einem für den Hauptthread. Im Watch-Modus verwendet Jest standardmäßig die Hälfte der verfügbaren Kerne, um Ressourcen zu schonen. Anpassungen können in ressourcenbeschränkten Umgebungen wie CI-Systemen sinnvoll sein, die Standardwerte sind jedoch für die meisten Anwendungsfälle angemessen.

Für Umgebungen mit variabler CPU-Verfügbarkeit können Sie eine prozentbasierte Konfiguration verwenden:

/** @type {import('jest').Config} */
const config = {
  maxWorkers: '50%',
};

module.exports = config;

moduleDirectories [array<string>]​

Standardwert: ["node_modules"]

Ein Array von Verzeichnisnamen, die rekursiv vom Ort des anfordernden Moduls durchsucht werden. Das Setzen dieser Option überschreibt den Standardwert. Wenn Sie weiterhin node_modules durchsuchen möchten, müssen Sie es explizit angeben:

/** @type {import('jest').Config} */
const config = {
  moduleDirectories: ['node_modules', 'bower_components'],
};

module.exports = config;
Vorsicht

Es wird davon abgeraten, '.' als eine der moduleDirectories zu verwenden, da dies verhindert, dass gepackte Pakete wie @emotion/react auf Pakete mit demselben Unterverzeichnisnamen (react) zugreifen können. Weitere Details finden Sie in diesem Issue. In den meisten Fällen ist es vorzuziehen, stattdessen die moduleNameMapper-Konfiguration zu verwenden.

moduleFileExtensions [array<string>]​

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

Ein Array von Dateiendungen, die Ihre Module verwenden. Wenn Sie Module ohne Angabe einer Dateiendung importieren, durchsucht Jest diese Endungen in der angegebenen Reihenfolge (von links nach rechts).

Wir empfehlen, die am häufigsten verwendeten Endungen in Ihrem Projekt links zu platzieren. Wenn Sie TypeScript verwenden, sollten Sie daher "ts" und/oder "tsx" an den Anfang des Arrays setzen.

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

Standardwert: null

Eine Zuordnung von regulären Ausdrücken zu Modulnamen oder Arrays von Modulnamen, die es ermöglicht, Ressourcen wie Bilder oder Styles mit einem einzigen Modul-Stub zu ersetzen.

Module, die einem Alias zugeordnet sind, werden standardmäßig nicht gemockt, unabhängig davon, ob Automocking aktiviert ist oder nicht.

Verwenden Sie den Platzhalter <rootDir>, um auf den Wert von rootDir zu verweisen, wenn Sie Dateipfade nutzen möchten.

Zusätzlich können Sie erfasste Regex-Gruppen mittels nummerierter Rückverweise ersetzen.

/** @type {import('jest').Config} */
const config = {
  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',
    ],
  },
};

module.exports = config;

Die Reihenfolge der Zuordnungen ist entscheidend. Muster werden nacheinander geprüft, bis eines passt. Die spezifischste Regel sollte zuerst stehen. Dies gilt auch für Arrays von Modulnamen.

Hinweis

Wenn Sie Modulnamen ohne Grenzen (^$) angeben, kann dies schwer erkennbare Fehler verursachen. Beispielsweise würde relay alle Module ersetzen, die relay als Teilstring enthalten: relay, react-relay und graphql-relay würden alle auf Ihren Stub verweisen.

modulePathIgnorePatterns [array<string>]​

Standard: []

Ein Array von Regex-Mustern, die gegen alle Modulpfade geprüft werden, bevor diese Pfade für den Modulloader "sichtbar" werden. Wenn der Pfad eines Moduls mit einem der Muster übereinstimmt, kann es in der Testumgebung nicht per require() geladen werden.

Diese Muster werden gegen den vollständigen Pfad geprüft. Verwenden Sie den Platzhalter <rootDir>, um Ihren Projekt-Root-Pfad einzubinden und zu vermeiden, dass fälschlich Dateien ignoriert werden – besonders in Umgebungen mit unterschiedlichen Root-Verzeichnissen.

/** @type {import('jest').Config} */
const config = {
  modulePathIgnorePatterns: ['<rootDir>/build/'],
};

module.exports = config;

modulePaths [array<string>]​

Standard: []

Eine Alternative zum Setzen der NODE_PATH-Umgebungsvariable. modulePaths ist ein Array absoluter Pfade zu zusätzlichen Orten, die bei der Modulauflösung durchsucht werden. Verwenden Sie <rootDir>, um den Pfad zum Projektstammverzeichnis einzubeziehen.

/** @type {import('jest').Config} */
const config = {
  modulePaths: ['<rootDir>/app/'],
};

module.exports = config;

notify [boolean]​

Standard: false

Aktiviert systemeigene Betriebssystem-Benachrichtigungen für Testergebnisse. Für Benachrichtigungen benötigt Jest das Paket node-notifier, das zusätzlich installiert werden muss:

npm install --save-dev node-notifier
Tipp

macOS: Erlauben Sie Benachrichtigungen von terminal-notifier unter Systemeinstellungen > Benachrichtigungen & Fokus.

Windows: Beim ersten Aufruf erstellt node-notifier einen neuen Startmenü-Eintrag und zeigt keine Benachrichtigung an. Ab dem zweiten Durchlauf werden Benachrichtigungen korrekt angezeigt.

notifyMode [string]​

Standardwert: failure-change

Legt den Benachrichtigungsmodus fest. Erfordert notify: true.

Modi​

  • always: Sendet immer eine Benachrichtigung.

  • failure: Sendet eine Benachrichtigung bei fehlgeschlagenen Tests.

  • success: Sendet eine Benachrichtigung bei bestandenen Tests.

  • change: Sendet eine Benachrichtigung bei Statusänderungen.

  • success-change: Sendet eine Benachrichtigung bei bestandenen Tests oder einmalig bei Fehlschlag.

  • failure-change: Sendet eine Benachrichtigung bei fehlgeschlagenen Tests oder einmalig bei Erfolg.

openHandlesTimeout [number]​

Standardwert: 1000

Zeigt eine Warnung an, wenn Jest nicht sauber beendet wird und nach Abschluss für diese Millisekundenanzahl wahrscheinlich offene Handles vorhanden sind. Verwende 0, um die Warnung zu deaktivieren.

preset [string]​

Standard: undefined

Ein Preset, das als Basis für Jests Konfiguration dient. Ein Preset sollte auf ein npm-Modul verweisen, das im Root eine jest-preset.json, jest-preset.js, jest-preset.cjs oder jest-preset.mjs Datei enthält.

Zum Beispiel wird das Preset foo-bar/jest-preset.js wie folgt konfiguriert:

/** @type {import('jest').Config} */
const config = {
  preset: 'foo-bar',
};

module.exports = config;

Presets können auch relative Dateisystempfade sein:

/** @type {import('jest').Config} */
const config = {
  preset: './node_modules/foo-bar/jest-preset.js',
};

module.exports = config;
Hinweis

Wenn zusätzlich rootDir angegeben ist, erfolgt die Auflösung dieser Datei relativ zu diesem Root-Verzeichnis.

prettierPath [string]​

Standardwert: 'prettier'

Legt den Pfad zum prettier-Node-Modul fest, das für die Aktualisierung von Inline-Snapshots verwendet wird.

Prettier version 3 is not supported!

You can either pass prettierPath: null in your config to disable using prettier if you don't need it, or use v2 of Prettier solely for Jest.

package.json
{
  "devDependencies": {
    "prettier-2": "npm:prettier@^2"
  }
}
/** @type {import('jest').Config} */
const config = {
  prettierPath: require.resolve('prettier-2'),
};

module.exports = config;

We hope to support Prettier v3 seamlessly out of the box in a future version of Jest. See this tracking issue.

projects [array<string | ProjectConfig>]​

Standard: undefined

Wenn die projects-Konfiguration ein Array von Pfaden oder Glob-Mustern enthält, führt Jest Tests in allen angegebenen Projekten gleichzeitig aus. Dies eignet sich hervorragend für Monorepos oder bei der Arbeit an mehreren Projekten.

/** @type {import('jest').Config} */
const config = {
  projects: ['<rootDir>', '<rootDir>/examples/*'],
};

module.exports = config;

Diese Beispielkonfiguration führt Jest im Root-Verzeichnis sowie in jedem Ordner des examples-Verzeichnisses aus. Es können beliebig viele Projekte in derselben Jest-Instanz laufen.

Die Projekte-Funktion kann auch verwendet werden, um mehrere Konfigurationen oder Runner auszuführen. Dazu kann ein Array von Konfigurationsobjekten übergeben werden. Beispiel zum gleichzeitigen Ausführen von Tests und ESLint (via jest-runner-eslint):

/** @type {import('jest').Config} */
const config = {
  projects: [
    {
      displayName: 'test',
    },
    {
      displayName: 'lint',
      runner: 'jest-runner-eslint',
      testMatch: ['<rootDir>/**/*.js'],
    },
  ],
};

module.exports = config;
Tipp

Bei Verwendung des Multi-Project-Runners wird empfohlen, jedem Projekt einen displayName hinzuzufügen. Dadurch wird der displayName neben den Tests des Projekts angezeigt.

Hinweis

Bei aktivierter projects-Option kopiert Jest die Root-Level-Konfigurationsoptionen während des Testlaufs in jede individuelle Child-Konfiguration und löst deren Werte im Kontext des Childs auf. Das bedeutet, dass Platzhalter wie <rootDir> auf das Root-Verzeichnis des Childs verweisen, selbst wenn sie in der Root-Konfiguration definiert sind.

randomize [boolean]​

Standard: false

Entspricht dem Flag --randomize, um die Reihenfolge der Tests in einer Datei zu randomisieren.

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

Standard: undefined

Verwende diese Konfigurationsoption, um Reporter zu Jest hinzuzufügen. Es muss eine Liste von Reporter-Namen sein. Zusätzliche Optionen können über die Tupel-Form übergeben werden:

/** @type {import('jest').Config} */
const config = {
  reporters: [
    'default',
    ['<rootDir>/custom-reporter.js', {banana: 'yes', pineapple: 'no'}],
  ],
};

module.exports = config;

Standard-Reporter​

Wenn benutzerdefinierte Reporter angegeben werden, überschreibt dies den Standard-Jest-Reporter. Wenn Sie ihn beibehalten möchten, muss 'default' als Reporter-Name übergeben werden:

/** @type {import('jest').Config} */
const config = {
  reporters: [
    'default',
    ['jest-junit', {outputDirectory: 'reports', outputName: 'report.xml'}],
  ],
};

module.exports = config;

GitHub Actions Reporter​

Bei Aufnahme in die Liste annotiert der integrierte GitHub Actions Reporter geänderte Dateien mit Testfehlermeldungen und gibt (bei Verwendung mit 'silent: false') Logs mit GitHub-Gruppenfunktionen für einfache Navigation aus. Beachten Sie, dass 'default' hier nicht verwendet werden sollte, da 'github-actions' dies bereits übernimmt. Vergessen Sie nicht, auch 'summary' einzubeziehen. Für reine Annotationen reicht der Reporter ohne Optionen, da der Standardwert von 'silent' 'true' ist:

/** @type {import('jest').Config} */
const config = {
  reporters: [['github-actions', {silent: false}], 'summary'],
};

module.exports = config;

Zusammenfassungs-Reporter​

Der Zusammenfassungs-Reporter gibt eine Übersicht aller Tests aus. Er ist Teil des Standard-Reporters und wird aktiviert, wenn 'default' in der Liste enthalten ist. Beispielsweise können Sie ihn als eigenständigen Reporter anstelle des Standard-Reporters oder zusammen mit dem Silent Reporter verwenden:

/** @type {import('jest').Config} */
const config = {
  reporters: ['jest-silent-reporter', 'summary'],
};

module.exports = config;

Der summary-Reporter akzeptiert Optionen. Da er im default-Reporter enthalten ist, können Sie Optionen auch dort übergeben.

/** @type {import('jest').Config} */
const config = {
  reporters: [['default', {summaryThreshold: 10}]],
};

module.exports = config;

Die Option summaryThreshold funktioniert folgendermaßen: Wenn die Gesamtzahl der Test-Suites diesen Schwellenwert überschreitet, wird nach allen Tests eine detaillierte Zusammenfassung fehlgeschlagener Tests ausgegeben. Der Standardwert ist 20.

Benutzerdefinierte Reporter​

Tipp

Sie hungern nach Reportern? Werfen Sie einen Blick auf die umfangreiche Liste beeindruckender Reporter von Awesome Jest.

Ein benutzerdefiniertes Reporter-Modul muss eine Klasse exportieren, die globalConfig, reporterOptions und reporterContext als Konstruktorargumente entgegennimmt:

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;
Hinweis

Die vollständige Liste der Hooks und Argumenttypen finden Sie in der Reporter-Schnittstelle unter packages/jest-reporters/src/types.ts.

resetMocks [boolean]​

Standard: false

Setzt den Mock-Zustand vor jedem Test automatisch zurück. Entspricht dem Aufruf von jest.resetAllMocks() vor jedem Test. Entfernt gefälschte Implementierungen aus Mocks, stellt aber keine ursprünglichen Implementierungen wieder her.

resetModules [boolean]​

Standard: false

Standardmäßig hat jede Testdatei eine unabhängige Modul-Registry. resetModules setzt diese Registry zusätzlich vor jedem einzelnen Test zurück. Dies isoliert Module zwischen Tests und verhindert Konflikte im lokalen Modulzustand. Entspricht programmatischem Aufruf von jest.resetModules().

resolver [string]​

Standard: undefined

Ermöglicht die Verwendung eines benutzerdefinierten Resolvers. Dieses Modul muss entweder exportieren:

  1. Eine Funktion, die einen String (Pfad) als erstes Argument und ein Optionsobjekt als zweites erwartet. Muss einen Pfad zum Modul zurückgeben oder einen Fehler werfen, wenn das Modul nicht gefunden wird. oder

  2. Ein Objekt mit async- und/oder sync-Eigenschaften. sync muss eine Funktion obiger Form sein, async muss eine gleichartige Funktion sein, die ein Promise mit dem Pfad oder einem Fehler zurückgibt.

Das an Resolver übergebene Optionsobjekt hat folgende Form:

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>;
  /** Allows transforming parsed `package.json` contents. */
  packageFilter?: (pkg: PackageJSON, file: string, dir: string) => PackageJSON;
  /** Allows transforms a path within a package. */
  pathFilter?: (pkg: PackageJSON, path: string, relativePath: string) => string;
  /** Current root directory. */
  rootDir?: string;
};
Tipp

Der als Option übergebene defaultResolver ist der standardmäßige Jest-Resolver, der beim Erstellen eines eigenen Resolvers nützlich sein kann. Er nimmt dieselben Argumente entgegen wie ein synchroner benutzerdefinierter Resolver (z.B. (path, options)) und gibt einen String zurück oder wirft einen Fehler.

Wenn Sie beispielsweise Browserifys "browser"-Feld berücksichtigen möchten, können Sie folgenden Resolver verwenden:

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

module.exports = browserResolve.sync;

Und diesen der Jest-Konfiguration hinzufügen:

/** @type {import('jest').Config} */
const config = {
  resolver: '<rootDir>/resolver.js',
};

module.exports = config;

Durch Kombination von defaultResolver und packageFilter können wir einen package.json-"Pre-Processor" implementieren, der beeinflusst, wie der Standard-Resolver Module auflöst. Beispiel: Wir möchten das Feld "module" verwenden, falls vorhanden, andernfalls auf "main" zurückfallen:

module.exports = (path, options) => {
  // Call the defaultResolver, so we leverage its cache, error handling, etc.
  return options.defaultResolver(path, {
    ...options,
    // Use packageFilter to process parsed `package.json` before the resolution (see https://www.npmjs.com/package/resolve#resolveid-opts-cb)
    packageFilter: pkg => {
      return {
        ...pkg,
        // Alter the value of `main` before resolving the package
        main: pkg.module || pkg.main,
      };
    },
  });
};

restoreMocks [boolean]​

Standard: false

Stellt automatisch vor jedem Test den ursprünglichen Zustand und die Implementierung von Mocks wieder her. Entspricht dem Aufruf von jest.restoreAllMocks() vor jedem Test. Dadurch werden Fälschungen entfernt und die Originalimplementierung wiederhergestellt.

rootDir [string]​

Standardwert: Das Wurzelverzeichnis mit Ihrer Jest-Konfigurationsdatei oder package.json oder pwd, falls keine package.json gefunden wird

Das Stammverzeichnis, in dem Jest nach Tests und Modulen suchen soll. Wenn Ihre Jest-Konfiguration in der package.json liegt und das Wurzelverzeichnis Ihres Repos sein soll, wird standardmäßig das Verzeichnis der package.json verwendet.

Oft setzt man dies auf 'src' oder 'lib', entsprechend dem Speicherort Ihres Codes im Repository.

Tipp

Durch Verwendung von '<rootDir>' als Platzhalter in pfadbasierten Konfigurationseinstellungen wird auf diesen Wert verwiesen. Wenn beispielsweise ein setupFiles-Eintrag auf die Datei some-setup.js im Projektstamm zeigen soll, setzen Sie den Wert auf: '<rootDir>/some-setup.js'.

roots [array<string>]​

Standardwert: ["<rootDir>"]

Eine Liste von Verzeichnispfaden, in denen Jest nach Dateien suchen soll.

Manchmal möchten Sie, dass Jest nur in einem Unterverzeichnis sucht (z.B. bei einem src/-Verzeichnis), aber den Zugriff auf den Rest des Repos verhindern.

Hinweis

Während rootDir hauptsächlich als wiederverwendbarer Platzhalter dient, nutzt Jest roots intern zum Auffinden von Testdateien und Quellcode. Dies gilt auch für manuelle Mocks von node_modules-Modulen (dafür muss __mocks__ in einem der roots-Verzeichnisse liegen).

Standardmäßig enthält roots nur <rootDir>, aber bei Projekten mit mehreren Wurzeln können Sie z.B. roots: ["<rootDir>/src/", "<rootDir>/tests/"] setzen.

runtime [string]​

Standard: "jest-runtime"

Diese Option ermöglicht die Verwendung einer benutzerdefinierten Runtime zur Ausführung von Testdateien. Eine benutzerdefinierte Runtime kann durch Angabe eines Pfads zu einer Runtime-Implementierung bereitgestellt werden.

Das Runtime-Modul muss eine Klasse exportieren, die die standardmäßige Runtime-Klasse von Jest erweitert oder eine kompatible Schnittstelle mit derselben Konstruktor-Signatur und denselben Methoden implementiert.

Warnung

Das Erstellen einer benutzerdefinierten Runtime ist ein fortgeschrittener Anwendungsfall. Die meisten Benutzer sollten die Runtime nicht anpassen müssen. Überlege, ob dein Anwendungsfall besser mit benutzerdefinierten Transformern, Testumgebungen oder Modul-Mocks gelöst werden kann.

Beispiel:

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
}

Füge die benutzerdefinierte Runtime deiner Jest-Konfiguration hinzu:

jest.config.js
module.exports = {
  runtime: './custom-runtime.js',
};

runner [string]​

Standardwert: "jest-runner"

Diese Option ermöglicht die Verwendung eines benutzerdefinierten Runners statt des Jest-Standardrunners. Beispiele für Runner:

Hinweis

Der Wert der runner-Eigenschaft kann das jest-runner--Präfix des Paketnamens weglassen.

Um einen Test-Runner zu erstellen, exportiere eine Klasse, die im Konstruktor globalConfig akzeptiert und eine runTests-Methode mit folgender Signatur besitzt:

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

Falls dein Test-Runner nur seriell statt parallel ausgeführt werden soll, muss deine Klasse die Eigenschaft isSerial auf true gesetzt haben.

sandboxInjectedGlobals [array<string>]​

Tipp

Umbenannt von extraGlobals in Jest 28.

Standard: undefined

Testdateien werden in einer vm ausgeführt, was Aufrufe von Eigenschaften des globalen Kontexts (z.B. Math) verlangsamt. Mit dieser Option kannst du zusätzliche Eigenschaften festlegen, die innerhalb der VM für schnellere Zugriffe definiert werden.

Wenn deine Tests beispielsweise häufig Math aufrufen, kannst du es durch Setzen von sandboxInjectedGlobals übergeben.

/** @type {import('jest').Config} */
const config = {
  sandboxInjectedGlobals: ['Math'],
};

module.exports = config;
Hinweis

Diese Option hat keine Wirkung, wenn du nativen ESM verwendest.

setupFiles [array]​

Standard: []

Eine Liste von Pfaden zu Modulen, die Code zur Konfiguration oder Einrichtung der Testumgebung ausführen. Jede Setup-Datei wird einmal pro Testdatei ausgeführt. Da jeder Test in seiner eigenen Umgebung läuft, werden diese Skripte in der Testumgebung ausgeführt, bevor setupFilesAfterEnv und vor dem eigentlichen Testcode ausgeführt werden.

Tipp

Falls dein Setup-Skript ein CJS-Modul ist, kann es eine asynchrone Funktion exportieren. Jest ruft die Funktion auf und wartet auf ihr Ergebnis. Dies kann nützlich sein, um asynchron Daten abzurufen. Bei ESM-Modulen verwende einfach Top-Level-Await für denselben Effekt.

setupFilesAfterEnv [array]​

Standard: []

Eine Liste von Pfaden zu Modulen, die Code zur Konfiguration oder Einrichtung des Testframeworks ausführen, bevor jede Testdatei der Suite ausgeführt wird. Während setupFiles vor der Installation des Testframeworks in der Umgebung ausgeführt wird, bietet diese Skriptdatei die Möglichkeit, Code unmittelbar nach der Installation des Testframeworks, aber vor dem eigentlichen Testcode auszuführen.

Mit anderen Worten: setupFilesAfterEnv-Module sind für Code gedacht, der in jeder Testdatei wiederholt wird. Das installierte Testframework macht Jest-Globals, das jest-Objekt und expect in den Modulen zugänglich. Beispielsweise kannst du zusätzliche Matcher aus der Bibliothek jest-extended hinzufügen oder Setup- und Teardown-Hooks aufrufen:

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

afterEach(() => {
  jest.useRealTimers();
});
/** @type {import('jest').Config} */
const config = {
  setupFilesAfterEnv: ['<rootDir>/setup-jest.js'],
};

module.exports = config;

showSeed [boolean]​

Standard: false

Entspricht dem --showSeed-Flag, um den Seed in der Testzusammenfassung auszugeben.

slowTestThreshold [number]​

Standard: 5

Die Anzahl Sekunden, nach denen ein Test als langsam eingestuft und entsprechend in den Ergebnissen gekennzeichnet wird.

snapshotFormat [object]​

Standardwert: {escapeString: false, printBasicPrototype: false}

Ermöglicht das Überschreiben spezifischer Formatierungsoptionen für Snapshots, wie im pretty-format Readme dokumentiert (Ausnahme: compareKeys und plugins). Beispielsweise würde diese Konfiguration bewirken, dass der Snapshot-Formatter keine Präfixe für "Object" und "Array" ausgibt:

/** @type {import('jest').Config} */
const config = {
  snapshotFormat: {
    printBasicPrototype: false,
  },
};

module.exports = config;
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

Pfad zu einem Modul, das Test-↔Snapshot-Pfade auflösen kann. Diese Option ermöglicht die Anpassung des Speicherorts von Snapshot-Dateien auf dem Datenträger.

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: []

Liste von Pfaden zu Snapshot-Serialisermodulen, die Jest für Snapshot-Tests verwenden soll.

Jest bietet Standardserialisierer für eingebaute JavaScript-Typen, HTML-Elemente (ab Jest 20.0.0+), ImmutableJS (ab Jest 20.0.0+) und React-Elemente. Weitere Informationen im Snapshot-Test-Tutorial.

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 ist eine Funktion, die Werte mit vorhandenen Plugins serialisiert.

Fügen Sie custom-serializer Ihrer Jest-Konfiguration hinzu:

/** @type {import('jest').Config} */
const config = {
  snapshotSerializers: ['path/to/custom-serializer.js'],
};

module.exports = config;

Die Tests würden schließlich wie folgt aussehen:

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

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

Gerenderter Snapshot:

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

Um eine Abhängigkeit explizit statt implizit zu machen, können Sie expect.addSnapshotSerializer für individuelle Testdateien verwenden, statt den Pfad zu snapshotSerializers in der Jest-Konfiguration hinzuzufügen.

Weitere Informationen zur Serializer-API finden Sie hier.

testEnvironment [string]​

Standardwert: "node"

Die Testumgebung, die für Tests verwendet wird. Die Standardumgebung in Jest ist eine Node.js-Umgebung. Für Webanwendungen kann stattdessen eine browserähnliche Umgebung via jsdom verwendet werden.

Durch einen @jest-environment-Docblock am Dateianfang kann eine andere Umgebung für alle Tests in dieser Datei festgelegt werden:

/**
 * @jest-environment jsdom
 */

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

Sie können ein eigenes Modul zur Einrichtung der Testumgebung erstellen. Dieses muss eine Klasse mit den Methoden setup, teardown und getVmContext exportieren. Variablen können via this.global an Testsuites übergeben werden – sie stehen dann als globale Variablen zur Verfügung. Der Konstruktor erhält globalConfig und projectConfig als ersten Argument sowie testEnvironmentContext als zweiten Parameter.

Die Klasse kann optional eine asynchrone Methode handleTestEvent bereitstellen, um auf Ereignisse von jest-circus zu reagieren. Normalerweise würde der jest-circus-Testrunner anhalten, bis ein von handleTestEvent zurückgegebenes Promise erfüllt ist, außer bei folgenden Ereignissen: start_describe_definition, finish_describe_definition, add_hook, add_test oder error (die aktuelle Liste finden Sie unter SyncEvent-Typ in den Typdefinitionen). Dies liegt an Abwärtskompatibilitätsgründen und der process.on('unhandledRejection', callback)-Signatur, stellt aber für die meisten Anwendungsfälle kein Problem dar.

Docblock-Pragmas in Testdateien werden an den Environment-Konstruktor übergeben und können für test-spezifische Konfigurationen genutzt werden. Wenn ein Pragma keinen Wert hat, erscheint es im Objekt mit einem leeren String als Wert. Fehlt das Pragma, wird es nicht im Objekt enthalten sein.

Um diese Klasse als benutzerdefinierte Testumgebung zu nutzen, referenzieren Sie sie über ihren vollständigen Projektpfad. Beispiel: Wenn Ihre Klasse in einem Unterordner Ihres Projekts in my-custom-environment.js gespeichert ist, dann würde die Annotation so aussehen:

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

Die Testumgebung läuft in einer Sandbox. Jede Testsuite triggert Setup/Teardown in ihrer eigenen TestEnvironment.

Beispiel:

// 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: {}

Optionen für die Testumgebung, die an testEnvironment übergeben werden. Die relevanten Optionen hängen vom jeweiligen Environment ab.

Beispiel für die Überschreibung von jsdom-Optionen:

/** @type {import('jest').Config} */
const config = {
  testEnvironment: 'jsdom',
  testEnvironmentOptions: {
    html: '<html lang="zh-cmn-Hant"></html>',
    url: 'https://jestjs.io/',
    userAgent: 'Agent/007',
  },
};

module.exports = config;

Sowohl jest-environment-jsdom als auch jest-environment-node erlauben die Angabe von customExportConditions, die steuern, welche Bibliotheksversionen aus exports in package.json geladen werden. jest-environment-jsdom nutzt standardmäßig ['browser'], jest-environment-node nutzt ['node', 'node-addons'].

/** @type {import('jest').Config} */
const config = {
  testEnvironment: 'jsdom',
  testEnvironmentOptions: {
    customExportConditions: ['react-native'],
  },
};

module.exports = config;

Diese Optionen können auch per Docblock übergeben werden, ähnlich wie testEnvironment. Der Options-String muss mit JSON.parse geparst werden können:

/**
 * @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

Der Exit-Code, den Jest bei Testfehlern zurückgibt.

Hinweis

Dies ändert nicht den Exit-Code bei Jest-internen Fehlern (z.B. ungültige Konfiguration).

testMatch [array<string>]​

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

Die Glob-Muster, die Jest zur Erkennung von Testdateien verwendet. Standardmäßig sucht es nach .js, .jsx, .ts und .tsx Dateien in __tests__-Ordnern sowie Dateien mit den Suffixen .test oder .spec (z.B. Component.test.js oder Component.spec.js). Es findet auch Dateien namens test.js oder spec.js.

Details zu möglichen Mustern finden Sie im micromatch-Paket.

Siehe auch testRegex [string | array<string>]. Hinweis: Beide Optionen können nicht gleichzeitig verwendet werden.

Tipp

Jedes Glob-Muster wird in der Reihenfolge der Konfiguration angewendet. Beispielsweise wird ["!**/__fixtures__/**", "**/__tests__/**/*.js"] den Ordner __fixtures__ nicht ausschließen, da die Negation durch das zweite Muster überschrieben wird. Damit die Negation funktioniert, muss sie nach **/__tests__/**/*.js stehen.

testPathIgnorePatterns [array<string>]​

Standard: ["/node_modules/"]

Ein Array von Regex-Mustern, die gegen alle Testpfade geprüft werden, bevor Tests ausgeführt werden. Wenn ein Testpfad mit einem der Muster übereinstimmt, wird er übersprungen.

Diese Muster werden mit dem vollständigen Pfad abgeglichen. Verwenden Sie den <rootDir>-Platzhalter, um den Pfad zum Projektstammverzeichnis einzubeziehen. Dies verhindert, dass versehentlich Dateien in verschiedenen Umgebungen mit unterschiedlichen Stammverzeichnissen ignoriert werden. Beispiel: ["<rootDir>/build/", "<rootDir>/node_modules/"].

testRegex [string | array<string>]​

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

Das Muster oder die Muster, die Jest zur Erkennung von Testdateien verwendet. Standardmäßig sucht es nach .js-, .jsx-, .ts- und .tsx-Dateien in __tests__-Ordnern sowie Dateien mit den Suffixen .test oder .spec (z.B. Component.test.js oder Component.spec.js). Es findet auch Dateien namens test.js oder spec.js. Siehe auch testMatch [array<string>], aber beachten Sie, dass Sie nicht beide Optionen gleichzeitig angeben können.

Hier eine Visualisierung des 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
Hinweis

testRegex versucht, Testdateien über den absoluten Dateipfad zu erkennen. Ein Ordner, dessen Name dem Muster entspricht, führt daher dazu, dass alle darin enthaltenen Dateien als Tests ausgeführt werden.

testResultsProcessor [string]​

Standard: undefined

Diese Option ermöglicht die Verwendung eines benutzerdefinierten Ergebnisprozessors. Dieser Prozessor muss ein Node-Modul sein, das eine Funktion exportiert, die ein Objekt mit folgender Struktur als ersten Parameter erwartet und zurückgibt:

{
  "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
    },
    ...
    ],
    "perfStats": {
      "start": epoch,
      "end": epoch
    },
    "testFilePath": absolute path to test file,
    "coverage": {}
  },
  "testExecError:" (exists if there was a top-level failure) {
    "message": string
    "stack": string
  }
  ...
  ]
}

testResultsProcessor und reporters sind sich sehr ähnlich. Ein Unterschied ist, dass ein Ergebnisprozessor erst nach Abschluss aller Tests aufgerufen wird. Ein Reporter kann hingegen Testergebnisse nach einzelnen Tests oder Testsuites erhalten.

testRunner [string]​

Standard: jest-circus/runner

Diese Option ermöglicht die Verwendung eines benutzerdefinierten Test-Runners. Der Standard ist jest-circus. Ein benutzerdefinierter Test-Runner kann durch Angabe eines Pfads zu einer entsprechenden Implementierung bereitgestellt werden.

Das Test-Runner-Modul muss eine Funktion mit folgender Signatur exportieren:

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

Ein Beispiel für eine solche Funktion finden Sie in unserem Standard-jasmine2 Test Runner Package.

testSequencer [string]​

Standard: @jest/test-sequencer

Diese Option ermöglicht die Verwendung eines benutzerdefinierten Sequenzers anstelle des Jest-Standards.

Tipp

Sowohl sort als auch shard können optional ein Promise zurückgeben.

Beispiel für alphabetische Sortierung von Testpfaden:

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;

Fügen Sie custom-sequencer Ihrer Jest-Konfiguration hinzu:

/** @type {import('jest').Config} */
const config = {
  testSequencer: 'path/to/custom-sequencer.js',
};

module.exports = config;

testTimeout [number]​

Standard: 5000

Standard-Timeout für einen Test in Millisekunden.

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

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

Eine Zuordnung von regulären Ausdrücken zu Pfaden von Transformern. Optional kann als zweites Argument ein Tupel mit Konfigurationsoptionen übergeben werden: {filePattern: ['path-to-transformer', {options}]}. Beispielsweise lässt sich so babel-jest für nicht standardmäßiges Verhalten konfigurieren: {'\\.js$': ['babel-jest', {rootMode: 'upward'}]}.

Jest führt den Code Ihres Projekts als JavaScript aus, daher ist ein Transformer erforderlich, wenn Sie Syntax verwenden, die von Node.js nicht nativ unterstützt wird (wie JSX, TypeScript, Vue-Templates). Standardmäßig verwendet Jest den babel-jest-Transformer, der die Babel-Konfiguration Ihres Projekts lädt und Dateien transformiert, die dem regulären Ausdruck /\.[jt]sx?$/ entsprechen (also .js, .jsx, .ts oder .tsx-Dateien). Zusätzlich fügt babel-jest das Babel-Plugin für Mock-Hoisting ein, das im Abschnitt ES Module mocking beschrieben wird.

Weitere Details und Anleitungen zum Erstellen eigener Transformer finden Sie im Abschnitt Code Transformation.

Tipp

Beachten Sie, dass ein Transformer jede Datei nur einmal verarbeitet, es sei denn, die Datei wurde geändert.

Vergessen Sie nicht, den Standard-babel-jest-Transformer explizit einzubinden, wenn Sie ihn zusammen mit zusätzlichen Präprozessoren verwenden möchten:

/** @type {import('jest').Config} */
const config = {
  transform: {
    '\\.[jt]sx?$': 'babel-jest',
    '\\.css$': 'some-css-transformer',
  },
};

module.exports = config;

transformIgnorePatterns [array<string>]​

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

Ein Array von Regex-Mustern, die gegen alle Quell-Dateipfade geprüft werden, bevor eine Transformation erfolgt. Wenn der Dateipfad irgendeines der Muster trifft, wird die Datei nicht transformiert.

Überlappende Regex-Muster können dazu führen, dass Dateien nicht transformiert werden, obwohl Sie es erwartet hätten. Beispiel:

/** @type {import('jest').Config} */
const config = {
  transformIgnorePatterns: ['/node_modules/(?!(foo|bar)/)', '/bar/'],
};

module.exports = config;

Das erste Muster ignoriert (und transformiert daher nicht) Dateien in /node_modules, außer in /node_modules/foo/ und /node_modules/bar/. Das zweite Muster ignoriert Dateien in allen Pfaden mit /bar/. Zusammen bewirken sie, dass Dateien in /node_modules/bar/ nicht transformiert werden – sie erfüllen das zweite Muster, obwohl sie vom ersten ausgenommen waren.

In manchen Projekten (besonders React Native oder TypeScript) werden Third-Party-Module manchmal nicht transpiliert veröffentlicht. Da Dateien in node_modules standardmäßig nicht transformiert werden, kann Jest diesen Code nicht verarbeiten, was zu Syntaxfehlern führt. Mit transformIgnorePatterns können Sie die Transformation solcher Module explizit erlauben. Ein gutes Beispiel finden Sie im React Native Guide.

Diese Muster werden gegen den vollständigen Pfad geprüft. Verwenden Sie den Platzhalter <rootDir>, um Ihren Projekt-Root-Pfad einzubinden und zu vermeiden, dass fälschlich Dateien ignoriert werden – besonders in Umgebungen mit unterschiedlichen Root-Verzeichnissen.

/** @type {import('jest').Config} */
const config = {
  transformIgnorePatterns: [
    '<rootDir>/bower_components/',
    '<rootDir>/node_modules/',
  ],
};

module.exports = config;
Tipp

Wenn Sie pnpm verwenden und Pakete unter node_modules transformieren müssen, beachten Sie: Pakete in diesem Ordner (z.B. node_modules/package-a/) sind symbolische Links zu .pnpm-Pfaden (z.B. node_modules/.pnpm/package-a@x.x.x/node_modules/package-a/). Daher wird <rootDir>/node_modules/(?!(package-a|@scope/pkg-b)/) nicht erkannt. Verwenden Sie stattdessen:

/** @type {import('jest').Config} */
const config = {
  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)',
  ],
};

module.exports = config;

Hinweis: Ordnernamen unter .pnpm setzen sich aus dem Paketnamen, dem Zeichen @ und der Versionsnummer zusammen. Daher wird das Schreiben von / nicht erkannt, aber die Verwendung von @ funktioniert.

unmockedModulePathPatterns [array<string>]​

Standard: []

Ein Array von Regex-Mustern, die vor dem automatischen Mocking durch den Modul-Loader auf alle Module angewendet werden. Wenn ein Modulpfad mit einem dieser Muster übereinstimmt, wird kein automatisches Mock erstellt.

Nützlich für häufig genutzte "Hilfsmodule" (wie underscore, lodash), die meist als Implementierungsdetails dienen. Bewahren Sie diese Liste möglichst klein und verwenden Sie stattdessen explizite jest.mock()/jest.unmock()-Aufrufe in einzelnen Tests. Explizite Test-Setups sind für andere Testleser besser nachvollziehbar.

Diese Einstellung kann in einzelnen Tests durch expliziten jest.mock()-Aufruf am Dateianfang überschrieben werden.

verbose [boolean]​

Standard: false oder true bei nur einer Testdatei

Steuert, ob jeder einzelne Test während der Ausführung gemeldet wird. Alle Fehler werden zusätzlich am Ende angezeigt.

watchPathIgnorePatterns [array<string>]​

Standard: []

Ein Array von RegExp-Mustern, die gegen alle Quelldateipfade abgeglichen werden, bevor Tests im Watch-Modus erneut ausgeführt werden. Wenn der Dateipfad einem der Muster entspricht, löst eine Aktualisierung keine erneute Testausführung aus.

Diese Muster werden gegen den vollständigen Pfad abgeglichen. Verwenden Sie den String-Token <rootDir>, um den Pfad zum Projektstammverzeichnis einzubeziehen und zu verhindern, dass in verschiedenen Umgebungen mit unterschiedlichen Stammverzeichnissen fälschlicherweise alle Dateien ignoriert werden. Beispiel: ["<rootDir>/node_modules/"].

Selbst wenn hier nichts angegeben ist, ignoriert der Watcher Änderungen an Versionskontrollordnern (.git, .hg, .sl). Andere versteckte Dateien und Verzeichnisse, also solche, die mit einem Punkt (.) beginnen, werden standardmäßig beobachtet. Denken Sie daran, den Punkt zu escapen, wenn Sie ihn zu watchPathIgnorePatterns hinzufügen, da es sich um ein Sonderzeichen in RegExp handelt.

/** @type {import('jest').Config} */
const config = {
  watchPathIgnorePatterns: ['<rootDir>/\\.tmp/', '<rootDir>/bar/'],
};

module.exports = config;

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

Standard: []

Diese Option ermöglicht die Verwendung benutzerdefinierter Watch-Plugins. Mehr dazu finden Sie hier.

Beispiele für Watch-Plugins sind:

Hinweis

In den Werten der watchPlugins-Eigenschaft kann das jest-watch--Präfix des Paketnamens weggelassen werden.

watchman [boolean]​

Standard: true

Legt fest, ob watchman für das Dateicrawling verwendet werden soll.

workerIdleMemoryLimit [number|string]​

Standard: undefined

Legt die Speichergrenze für Worker fest, bevor sie recycelt werden. Dient primär als Workaround für dieses Problem.

Nachdem ein Worker einen Test ausgeführt hat, wird sein Speicherverbrauch geprüft. Wenn der festgelegte Wert überschritten wird, wird der Worker beendet und neu gestartet. Das Limit kann auf verschiedene Arten angegeben werden, wobei Math.floor verwendet wird, um es in einen ganzzahligen Wert umzuwandeln:

  • 0 - Worker zwischen Tests immer neu starten.

  • <= 1 - Der Wert wird als Prozentsatz des Systemspeichers interpretiert. 0.5 setzt das Speicherlimit des Workers auf die Hälfte des gesamten Systemspeichers.

  • \> 1 - Wird als fester Byte-Wert interpretiert. Aufgrund der vorherigen Regel kann für 1 Byte (unüblich) 1.1 verwendet werden.

  • Mit Einheiten:

    • 50% - Wie oben, Prozentsatz des gesamten Systemspeichers
    • 100KB, 65MB, etc - Festes Speicherlimit mit Einheiten:
      • K / KB - Kilobytes (x1000)
      • KiB - Kibibytes (x1024)
      • M / MB - Megabytes
      • MiB - Mebibytes
      • G / GB - Gigabytes
      • GiB - Gibibytes
Vorsicht

Prozentbasierte Speicherlimits funktionieren nicht auf Linux-CircleCI-Workern, da der Systemspeicher falsch gemeldet wird.

/** @type {import('jest').Config} */
const config = {
  workerIdleMemoryLimit: 0.2,
};

module.exports = config;

// [string]​

Diese Option ermöglicht Kommentare in package.json. Fügen Sie den Kommentartext als Wert dieses Schlüssels ein:

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

workerThreads​

Standard: false

Legt fest, ob Worker-Threads für die Parallelisierung verwendet werden sollen. Standardmäßig werden Child Processes verwendet.

Die Verwendung von Worker-Threads kann helfen, die Performance zu verbessern.

Vorsicht

Dies ist eine experimentelle Funktion. Beachten Sie, dass Worker-Threads statt JSON.stringify() einen strukturierten Klon zur Nachrichtenserialisierung verwenden. Eingebaute JavaScript-Objekte wie BigInt, Map oder Set werden korrekt serialisiert. Zusätzliche Eigenschaften auf Error, Map oder Set werden jedoch nicht serialisiert. Weitere Details finden Sie im Artikel zu strukturierten Klon.