Vitest konfigurieren

Um eine Vitest-Konfigurationsdatei zu erstellen, folgen Sie dieser Anleitung. Stellen Sie sicher, dass Sie die Funktionsweise der Vitest-Konfigurationsauflösung verstehen, bevor Sie fortfahren.

WARNING

Alle hier aufgeführten Optionen befinden sich in der test-Eigenschaft innerhalb der Konfiguration:

export default defineConfig({
  test: {
    exclude: [],
  },
});

TIP

Zusätzlich zu den folgenden Optionen können Sie auch jede Konfigurationsoption von Vite verwenden. Zum Beispiel define, um globale Variablen zu definieren, oder resolve.alias, um Aliase zu definieren.

Alle Konfigurationsoptionen, die nicht innerhalb einer Workspace-Projektkonfiguration unterstützt werden, sind mit einem *-Zeichen versehen.

include

Typ: string[]
Standardwert: ['**/*.{test,spec}.?(c|m)[jt]s?(x)']
CLI: vitest [...include], vitest **/*.test.js

Eine Liste von Glob-Mustern, die auf Ihre Testdateien passen.

exclude

Typ: string[]
Standardwert: ['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**', '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build}.config.*']
CLI: vitest --exclude "**/excluded-file"

Eine Liste von Glob-Mustern, die bei der Suche nach Testdateien ausgeschlossen werden sollen.

WARNING

Diese Option hat keine Auswirkungen auf die Codeabdeckung. Wenn Sie bestimmte Dateien aus dem Coverage-Bericht entfernen müssen, verwenden Sie coverage.exclude.

Dies ist die einzige Option, die Ihre Konfiguration nicht überschreibt, wenn Sie sie mit einem CLI-Flag angeben. Alle Glob-Muster, die über das --exclude-Flag hinzugefügt werden, werden der exclude-Konfiguration hinzugefügt.

includeSource

Typ: string[]
Standardwert: []

Glob-Muster für In-Source-Testdateien.

Wenn diese Option definiert ist, führt Vitest alle übereinstimmenden Dateien aus, die import.meta.vitest enthalten.

server 0.34.0+

Typ: { sourcemap?, deps?, ... }

Vite-Node Server Optionen.

server.sourcemap

Typ: 'inline' | boolean
Standardwert: 'inline'

Fügt Inline-Source-Maps in die Module ein.

server.debug

Typ: { dumpModules?, loadDumppedModules? }

Vite-Node Debugger Optionen.

server.debug.dumpModules

Typ: boolean | string

Schreibt das transformierte Modul in das Dateisystem. Wenn eine Zeichenkette übergeben wird, wird es in den angegebenen Pfad geschrieben.

server.debug.loadDumppedModules

Typ: boolean

Liest das gespeicherte Modul aus dem Dateisystem, falls es vorhanden ist. Nützlich für das Debuggen durch Ändern des Speicherergebnisses aus dem Dateisystem.

server.deps

Typ: { external?, inline?, ... }

Verwaltung der Auflösung von Abhängigkeiten.

server.deps.external

Typ: (string | RegExp)[]
Standardwert: [/\/node_modules\//]

Bei der Externalisierung übergibt Vite das Paket an den nativen Node. Externalisierte Abhängigkeiten werden nicht auf die Transformer und Resolver von Vite angewendet, sodass sie kein HMR beim Neuladen unterstützen. Standardmäßig werden alle Pakete innerhalb von node_modules externalisiert.

Diese Optionen unterstützen Paketnamen in ihrer ursprünglichen Schreibweise, wie sie in node_modules geschrieben oder innerhalb von deps.moduleDirectories angegeben sind. Zum Beispiel sollte das Paket @company/some-name, das sich innerhalb von packages/some-name befindet, als some-name angegeben werden, und packages sollte in deps.moduleDirectories enthalten sein. Vitest überprüft stets den Dateipfad, nicht den tatsächlichen Paketnamen.

Wenn ein regulärer Ausdruck verwendet wird, wird er von Vitest auf den Dateipfad und nicht auf den Paketnamen angewendet.

server.deps.inline

Typ: (string | RegExp)[] | true
Standardwert: []

Vite verarbeitet Inline-Module. Dies kann hilfreich sein, um Pakete zu verarbeiten, die .js im ESM-Format ausliefern (das Node nicht verarbeiten kann).

Wenn true, wird jede Abhängigkeit inline eingebunden. Alle Abhängigkeiten, die in ssr.noExternal angegeben sind, werden standardmäßig inline verwendet.

server.deps.fallbackCJS

Typ boolean
Standardwert: false

Wenn eine Abhängigkeit ein gültiges ESM-Paket ist, wird versucht, die CJS-Version basierend auf dem Pfad zu ermitteln. Dies kann nützlich sein, wenn eine Abhängigkeit die falsche ESM-Datei hat.

Dies könnte möglicherweise zu einer Fehlausrichtung führen, wenn ein Paket im ESM- und CJS-Modus unterschiedliche Logiken aufweist.

server.deps.cacheDir

Typ string
Standardwert: 'node_modules/.vite'

Verzeichnis, in dem Cache-Dateien gespeichert werden.

deps

Typ: { optimizer?, ... }

Verwaltung der Auflösung von Abhängigkeiten.

deps.optimizer 0.34.0+

Typ: { ssr?, web? }
Siehe auch: Dep Optimization Options

Aktivieren Sie die Abhängigkeitsoptimierung. Wenn Sie viele Tests haben, kann dies ihre Leistung verbessern. Vor Vitest 0.34.0 wurde diese Option als deps.experimentalOptimizer bezeichnet.

Wenn Vitest auf eine externe Bibliothek stößt, die in include aufgeführt ist, wird diese mit esbuild in eine einzige Datei gebündelt und als vollständiges Modul importiert. Dies bietet mehrere Vorteile:

Das Importieren von Paketen mit vielen Importen ist aufwendig. Indem wir sie in einer Datei bündeln, können wir viel Zeit sparen.
Das Importieren von UI-Bibliotheken ist aufwendig, da sie nicht für die Ausführung innerhalb von Node.js gedacht sind.
Ihre alias-Konfiguration wird jetzt innerhalb von gebündelten Paketen berücksichtigt.
Der Code in Ihren Tests wird ähnlicher dem Code ausgeführt, der im Browser läuft.

Beachten Sie, dass nur Pakete in der Option deps.optimizer?.[mode].include gebündelt werden (einige Plugins füllen dies automatisch aus, wie Svelte). Sie können mehr über die verfügbaren Optionen in der Vite-Dokumentation lesen (Vitest unterstützt die Optionen disable und noDiscovery nicht). Standardmäßig verwendet Vitest optimizer.web für jsdom- und happy-dom-Umgebungen und optimizer.ssr für node- und edge-Umgebungen, aber dies ist über transformMode konfigurierbar.

Diese Optionen erben auch Ihre optimizeDeps-Konfiguration (für Web erweitert Vitest optimizeDeps, für SSR - ssr.optimizeDeps). Wenn Sie die Option include/exclude in deps.optimizer neu definieren, wird sie Ihre optimizeDeps erweitern, wenn Sie Tests ausführen. Vitest entfernt automatisch die gleichen Optionen aus include, wenn sie in exclude aufgeführt sind.

TIP

Sie können Ihren node_modules-Code nicht zum Debuggen bearbeiten, da sich der Code tatsächlich in Ihrem cacheDir- oder test.cache.dir-Verzeichnis befindet. Wenn Sie mit console.log-Anweisungen debuggen möchten, bearbeiten Sie ihn direkt oder erzwingen Sie eine erneute Bündelung mit der Option deps.optimizer?.[mode].force.

deps.optimizer.{mode}.enabled

Typ: boolean
Standardwert: false seit Vitest 1.3.0

Aktivieren Sie die Abhängigkeitsoptimierung.

WARNING

Diese Option funktioniert nur mit Vite 4.3.2 und höher.

deps.web 0.34.2+

Typ: { transformAssets?, ... }

Optionen, die auf externe Dateien angewendet werden, wenn der Transformationsmodus auf web gesetzt ist. Standardmäßig verwenden jsdom und happy-dom den web-Modus, während node- und edge-Umgebungen den ssr-Transformationsmodus verwenden, sodass diese Optionen keine Auswirkungen auf Dateien in diesen Umgebungen haben.

Normalerweise werden Dateien innerhalb von node_modules externalisiert, aber diese Optionen wirken sich auch auf Dateien in server.deps.external aus.

deps.web.transformAssets

Typ: boolean
Standardwert: true

Soll Vitest Asset-Dateien (.png, .svg, .jpg usw.) verarbeiten und sie wie Vite im Browser behandeln?

Dieses Modul hat einen Standardexport, der dem Pfad zum Asset entspricht, wenn keine Abfrage angegeben ist.

WARNING

Im Moment funktioniert diese Option nur mit vmThreads- und vmForks-Pools.

deps.web.transformCss

Typ: boolean
Standardwert: true

Soll Vitest CSS-Dateien (.css, .scss, .sass usw.) verarbeiten und sie wie Vite im Browser behandeln?

Wenn CSS-Dateien mit css-Optionen deaktiviert sind, unterdrückt diese Option nur ERR_UNKNOWN_FILE_EXTENSION-Fehler.

WARNING

Im Moment funktioniert diese Option nur mit vmThreads- und vmForks-Pools.

deps.web.transformGlobPattern

Typ: RegExp | RegExp[]
Standardwert: []

Regexp-Muster, um externe Dateien abzugleichen, die transformiert werden sollen.

Standardmäßig werden Dateien innerhalb von node_modules externalisiert und nicht transformiert, es sei denn, es handelt sich um CSS oder ein Asset, und die entsprechende Option ist nicht deaktiviert.

WARNING

Im Moment funktioniert diese Option nur mit vmThreads- und vmForks-Pools.

deps.interopDefault

Typ: boolean
Standardwert: true

Behandelt den Standardexport von CJS-Modulen als benannte Exporte. Einige Abhängigkeiten bündeln nur CJS-Module und verwenden keine benannten Exporte, die Node.js statisch analysieren kann, wenn ein Paket mit der import-Syntax anstelle von require importiert wird. Wenn Sie solche Abhängigkeiten in der Node-Umgebung mit benannten Exporten importieren, wird dieser Fehler angezeigt:

import { read } from 'fs-jetpack';
         ^^^^
SyntaxError: Named export 'read' not found. The requested module 'fs-jetpack' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export.

Vitest führt keine statische Analyse durch und kann nicht fehlschlagen, bevor Ihr Code ausgeführt wird. Daher werden Sie diesen Fehler höchstwahrscheinlich beim Ausführen von Tests sehen, wenn diese Funktion deaktiviert ist:

TypeError: createAsyncThunk is not a function
TypeError: default is not a function

Standardmäßig nimmt Vitest an, dass Sie einen Bundler verwenden, um dies zu umgehen, und schlägt nicht fehl, aber Sie können dieses Verhalten manuell deaktivieren, wenn Ihr Code nicht verarbeitet wird.

deps.moduleDirectories

Typ: string[]
Standardwert: ['node_modules']

Eine Liste von Verzeichnissen, die als Modulverzeichnisse behandelt werden sollen. Diese Konfigurationsoption beeinflusst das Verhalten von vi.mock: Wenn keine Factory bereitgestellt wird und der Pfad dessen, was Sie mocken, mit einem der moduleDirectories-Werte übereinstimmt, versucht Vitest, den Mock aufzulösen, indem es nach einem __mocks__-Ordner im Root des Projekts sucht.

Diese Option beeinflusst auch, ob eine Datei als Modul behandelt werden soll, wenn Abhängigkeiten externalisiert werden. Standardmäßig importiert Vitest externe Module mit nativem Node.js, wobei der Vite-Transformationsschritt umgangen wird.

Das Festlegen dieser Option überschreibt den Standardwert. Wenn Sie weiterhin node_modules nach Paketen durchsuchen möchten, fügen Sie es zusammen mit anderen Optionen hinzu:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    deps: {
      moduleDirectories: ['node_modules', path.resolve('../../packages')],
    },
  },
});

runner

Typ: VitestRunnerConstructor
Standardwert: node, wenn Tests ausgeführt werden, oder benchmark, wenn Benchmarks ausgeführt werden

Pfad zu einem benutzerdefinierten Test Runner. Dies ist eine erweiterte Funktion und sollte mit benutzerdefinierten Bibliotheks-Runnern verwendet werden. Weitere Informationen finden Sie in der Dokumentation.

benchmark

Typ: { include?, exclude?, ... }

Optionen, die beim Ausführen von vitest bench verwendet werden.

benchmark.include

Typ: string[]
Standardwert: ['**/*.{bench,benchmark}.?(c|m)[jt]s?(x)']

Glob-Muster für Benchmark-Testdateien.

benchmark.exclude

Typ: string[]
Standardwert: ['node_modules', 'dist', '.idea', '.git', '.cache']

Glob-Muster zum Ausschließen von Benchmark-Testdateien.

benchmark.includeSource

Typ: string[]
Standardwert: []

Glob-Muster für In-Source-Benchmark-Testdateien. Diese Option ist ähnlich wie includeSource.

Wenn diese Option definiert ist, führt Vitest alle übereinstimmenden Dateien aus, die import.meta.vitest enthalten.

benchmark.reporters

Typ: Arrayable<BenchmarkBuiltinReporters | Reporter>
Standardwert: 'default'

Benutzerdefinierte Reporter für die Ausgabe. Kann einen oder mehrere integrierte Berichtsnamen, Reporter-Instanzen und/oder Pfade zu benutzerdefinierten Reportern enthalten.

benchmark.outputFile

Typ: string | Record<string, string>

Schreibt Benchmark-Ergebnisse in eine Datei, wenn auch die Option --reporter=json angegeben ist. Indem Sie ein Objekt anstelle einer Zeichenkette angeben, können Sie einzelne Ausgaben definieren, wenn Sie mehrere Reporter verwenden.

Um ein Objekt über einen CLI-Befehl bereitzustellen, verwenden Sie die folgende Syntax: --outputFile.json=./path --outputFile.junit=./other-path.

benchmark.outputJson 1.6.0+

Typ: string | undefined
Standardwert: undefined

Ein Dateipfad zum Speichern des Benchmark-Ergebnisses, das später für die Verwendung mit der Option --compare genutzt werden kann.

Zum Beispiel:

# Ergebnis des Hauptzweigs speichern
git checkout main
vitest bench --outputJson main.json

# Zweig wechseln und mit Hauptzweig vergleichen
git checkout feature
vitest bench --compare main.json

benchmark.compare 1.6.0+

Typ: string | undefined
Standardwert: undefined

Ein Dateipfad zu einem vorherigen Benchmark-Ergebnis, das mit den aktuellen Ausführungen verglichen werden soll.

alias

Typ: Record<string, string> | Array<{ find: string | RegExp, replacement: string, customResolver?: ResolverFunction | ResolverObject }>

Definieren Sie benutzerdefinierte Aliase, wenn Sie innerhalb von Tests ausführen. Sie werden mit Aliasen aus resolve.alias zusammengeführt.

WARNING

Vitest verwendet Vite SSR-Primitive, um Tests auszuführen, was gewisse Tücken birgt.

Aliase wirken sich nur auf Module aus, die direkt mit einem import-Schlüsselwort von einem inlined-Modul importiert werden (der gesamte Quellcode wird standardmäßig inline verwendet).
Vitest unterstützt keine Aliasierung von require-Aufrufen.
Wenn Sie eine externe Abhängigkeit aliasieren (z. B. react -> preact), sollten Sie stattdessen die tatsächlichen node_modules-Pakete aliasieren, damit es für externalisierte Abhängigkeiten funktioniert. Sowohl Yarn als auch pnpm unterstützen die Aliasierung über das npm:-Präfix.

globals

Typ: boolean
Standardwert: false
CLI: --globals, --globals=false

Standardmäßig stellt vitest keine globalen APIs bereit, um die Eindeutigkeit zu gewährleisten. Wenn Sie die APIs lieber global wie Jest verwenden möchten, können Sie die Option --globals an die CLI übergeben oder globals: true in der Konfiguration hinzufügen.

// vitest.config.ts
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true,
  },
});

Um TypeScript mit den globalen APIs nutzen zu können, fügen Sie vitest/globals zum Feld types in Ihrer tsconfig.json hinzu.

json

// tsconfig.json
{
  "compilerOptions": {
    "types": ["vitest/globals"]
  }
}

Wenn Sie bereits unplugin-auto-import in Ihrem Projekt verwenden, können Sie es auch direkt verwenden, um diese APIs automatisch zu importieren.

// vitest.config.ts
import { defineConfig } from 'vitest/config';
import AutoImport from 'unplugin-auto-import/vite';

export default defineConfig({
  plugins: [
    AutoImport({
      imports: ['vitest'],
      dts: true, // generate TypeScript declaration
    }),
  ],
});

environment

Typ: 'node' | 'jsdom' | 'happy-dom' | 'edge-runtime' | string
Standardwert: 'node'
CLI: --environment=<env>

Die Umgebung, die für die Tests verwendet wird. Die Standardumgebung in Vitest ist eine Node.js-Umgebung. Wenn Sie eine Webanwendung entwickeln, können Sie eine Browser-ähnliche Umgebung entweder über jsdom oder happy-dom nutzen. Für Edge-Funktionen steht die edge-runtime-Umgebung zur Verfügung.

Sie können eine andere Umgebung für alle Tests innerhalb einer Datei festlegen, indem Sie am Anfang der Datei einen @vitest-environment-Docblock oder -Kommentar hinzufügen:

Docblock-Format:

/**
 * @vitest-environment jsdom
 */

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

Kommentar-Format:

// @vitest-environment happy-dom

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

Zur Kompatibilität mit Jest wird auch @jest-environment unterstützt:

/**
 * @jest-environment jsdom
 */

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

Wenn Vitest mit dem Flag --isolate=false ausgeführt wird, werden die Tests in der folgenden Reihenfolge ausgeführt: node, jsdom, happy-dom, edge-runtime, custom environments (benutzerdefinierte Umgebungen). Das bedeutet, dass Tests mit derselben Umgebung gruppiert, aber dennoch sequenziell ausgeführt werden.

Ab Version 0.23.0 können Sie auch eine benutzerdefinierte Umgebung definieren. Wenn eine nicht integrierte Umgebung verwendet wird, versucht Vitest, das Paket vitest-environment-${name} zu laden. Dieses Paket sollte ein Objekt mit der Form Environment exportieren:

import type { Environment } from 'vitest';

export default <Environment>{
  name: 'custom',
  transformMode: 'ssr',
  setup() {
    // custom setup
    return {
      teardown() {
        // wird aufgerufen, nachdem alle Tests mit dieser Umgebung ausgeführt wurden
      },
    };
  },
};

Vitest stellt außerdem builtinEnvironments über den Eintrag vitest/environments bereit, falls Sie diese lediglich erweitern möchten. Weitere Informationen zum Erweitern von Umgebungen finden Sie in unserem Leitfaden.

TIP

Ab Vitest 1.3.0 stellt die jsdom-Umgebung die globale Variable jsdom bereit, die der aktuellen JSDOM-Instanz entspricht. Damit TypeScript diese Variable erkennt, können Sie vitest/jsdom zu Ihrer tsconfig.json hinzufügen, wenn Sie diese Umgebung verwenden:

json

{
  "compilerOptions": {
    "types": ["vitest/jsdom"]
  }
}

environmentOptions

Typ: Record<'jsdom' | string, unknown>
Standardwert: {}

Diese Optionen werden an die setup-Methode der aktuellen environment übergeben. Standardmäßig können Sie nur JSDOM-Optionen konfigurieren, wenn Sie diese als Testumgebung verwenden.

environmentMatchGlobs

Typ: [string, EnvironmentName][]
Standardwert: []

Weist die Umgebung automatisch anhand von Globs zu. Die erste Übereinstimmung wird verwendet.

Zum Beispiel:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environmentMatchGlobs: [
      // alle Tests in tests/dom werden in jsdom ausgeführt
      ['tests/dom/**', 'jsdom'],
      // alle Tests in tests/ mit .edge.test.ts werden in edge-runtime ausgeführt
      ['**/*.edge.test.ts', 'edge-runtime'],
      // ...
    ],
  },
});

poolMatchGlobs 0.29.4+

Typ: [string, 'threads' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]
Standardwert: []

Weist automatisch den Pool zu, in dem die Tests anhand von Globs ausgeführt werden. Die erste Übereinstimmung wird verwendet.

Zum Beispiel:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolMatchGlobs: [
      // alle Tests im Verzeichnis "worker-specific" werden in einem Worker ausgeführt, als ob Sie `--pool=threads` für sie aktiviert hätten
      ['**/tests/worker-specific/**', 'threads'],
      // Führen Sie alle Tests im Verzeichnis "browser" in einem tatsächlichen Browser aus
      ['**/tests/browser/**', 'browser'],
      // alle anderen Tests werden basierend auf den Optionen "browser.enabled" und "threads" ausgeführt, wenn Sie keine anderen Globs angegeben haben
      // ...
    ],
  },
});

update*

Typ: boolean
Standardwert: false
CLI: -u, --update, --update=false

Aktualisiert Snapshot-Dateien. Dadurch werden alle geänderten Snapshots aktualisiert und veraltete gelöscht.

watch*

Typ: boolean
Standardwert: !process.env.CI
CLI: -w, --watch, --watch=false

Aktiviert den Überwachungsmodus.

root

Typ: string
CLI: -r <Pfad>, --root=<Pfad>

Projektstammverzeichnis.

reporters*

Typ: Reporter | Reporter[]
Standardwert: 'default'
CLI: --reporter=<Name>, --reporter=<Name1> --reporter=<Name2>

Benutzerdefinierte Reporter für die Ausgabe. Reporter können eine Reporter-Instanz, ein String zur Auswahl integrierter Reporter oder ein Pfad zu einer benutzerdefinierten Implementierung sein (z. B. './path/to/reporter.ts', '@scope/reporter').

outputFile*

Typ: string | Record<string, string>
CLI: --outputFile=<Pfad>, --outputFile.json=./Pfad

Schreibt Testergebnisse in eine Datei, wenn auch die Option --reporter=json, --reporter=html oder --reporter=junit angegeben ist. Indem anstelle eines Strings ein Objekt angegeben wird, können Sie einzelne Ausgaben definieren, wenn Sie mehrere Reporter verwenden.

pool* 1.0.0+

Typ: 'threads' | 'forks' | 'vmThreads' | 'vmForks'
Standardwert: 'threads'
CLI: --pool=threads

Pool, der zum Ausführen von Tests verwendet wird.

threads*

Aktiviert Multi-Threading mit tinypool (einem leichtgewichtigen Fork von Piscina). Bei der Verwendung von Threads können keine prozessbezogenen APIs wie process.chdir() verwendet werden. Einige in nativen Sprachen geschriebene Bibliotheken, wie Prisma, bcrypt und canvas, haben Probleme, wenn sie in mehreren Threads ausgeführt werden und Segfaults verursachen. In diesen Fällen wird empfohlen, stattdessen den forks-Pool zu verwenden.

forks*

Ähnlich wie der threads-Pool, verwendet aber child_process anstelle von worker_threads über tinypool. Die Kommunikation zwischen Tests und dem Hauptprozess ist nicht so schnell wie mit dem threads-Pool. Prozessbezogene APIs wie process.chdir() sind im forks-Pool verfügbar.

vmThreads*

Führt Tests mit VM-Context (innerhalb einer Sandbox-Umgebung) in einem threads-Pool aus.

Dadurch werden Tests schneller ausgeführt, aber das VM-Modul ist instabil, wenn ESM-Code ausgeführt wird. Die Tests können Speicherlecks verursachen. Um dem entgegenzuwirken, sollte der Wert poolOptions.vmThreads.memoryLimit manuell angepasst werden.

WARNING

Das Ausführen von Code in einer Sandbox hat einige Vorteile (schnellere Tests), ist aber auch mit einer Reihe von Nachteilen verbunden.

Die globalen Variablen innerhalb nativer Module, wie z. B. (fs, path usw.), unterscheiden sich von den globalen Variablen, die in Ihrer Testumgebung vorhanden sind. Infolgedessen bezieht sich jeder Fehler, der von diesen nativen Modulen ausgelöst wird, auf einen anderen Error-Konstruktor als den, der in Ihrem Code verwendet wird:

try {
  fs.writeFileSync('/doesnt exist');
} catch (err) {
  console.log(err instanceof Error); // false
}

Das Importieren von ES-Modulen speichert sie auf unbestimmte Zeit im Cache, was zu Speicherlecks führt, wenn Sie viele Kontexte (Testdateien) haben. Es gibt keine API in Node.js, die diesen Cache löscht.
Der Zugriff auf globale Variablen dauert länger in einer Sandbox-Umgebung.

Bitte beachten Sie diese Probleme, wenn Sie diese Option verwenden. Das Vitest-Team kann keines der Probleme auf unserer Seite beheben.

vmForks*

Ähnlich wie der vmThreads-Pool, verwendet aber child_process anstelle von worker_threads über tinypool. Die Kommunikation zwischen Tests und dem Hauptprozess ist nicht so schnell wie mit dem vmThreads-Pool. Prozessbezogene APIs wie process.chdir() sind im vmForks-Pool verfügbar. Bitte beachten Sie, dass dieser Pool die gleichen Fallstricke wie in vmThreads aufweist.

poolOptions* 1.0.0+

Typ: Record<'threads' | 'forks' | 'vmThreads' | 'vmForks', {}>
Standardwert: {}

poolOptions.threads

Optionen für den threads-Pool.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      threads: {
        // Threads related options here
      },
    },
  },
});

poolOptions.threads.maxThreads*

Typ: number
Standardwert: verfügbare CPU-Kerne

Maximale Anzahl von Threads. Sie können auch die Umgebungsvariable VITEST_MAX_THREADS verwenden.

poolOptions.threads.minThreads*

Typ: number
Standardwert: verfügbare CPU-Kerne

Minimale Anzahl von Threads. Sie können auch die Umgebungsvariable VITEST_MIN_THREADS verwenden.

poolOptions.threads.singleThread

Typ: boolean
Standardwert: false

Führt alle Tests in einem einzigen Worker-Thread mit derselben Umgebung aus. Dadurch wird die integrierte Modulisolierung deaktiviert (Ihr Quellcode oder inline-Code wird weiterhin für jeden Test neu ausgewertet), kann aber die Testleistung verbessern.

WARNING

Auch wenn diese Option erzwingt, dass Tests nacheinander ausgeführt werden, unterscheidet sie sich von Jests --runInBand. Vitest verwendet Worker-Prozesse nicht nur, um Tests parallel auszuführen, sondern auch, um eine Isolierung zu gewährleisten. Durch Deaktivieren dieser Option werden Ihre Tests sequenziell, aber im selben globalen Kontext ausgeführt, sodass Sie die Isolierung selbst bereitstellen müssen.

Dies kann zu allen möglichen Problemen führen, wenn Sie sich auf den globalen Zustand verlassen (Frontend-Frameworks tun dies normalerweise) oder Ihr Code darauf angewiesen ist, dass die Umgebung für jeden Test separat definiert wird. Dies kann jedoch zu einer deutlichen Geschwindigkeitssteigerung der Tests führen (bis zu 3-mal schneller), wenn diese nicht zwingend auf einen globalen Zustand angewiesen sind oder diesen leicht umgehen können.

poolOptions.threads.useAtomics*

Typ: boolean
Standardwert: false

Verwendet Atomics, um Threads zu synchronisieren.

Dies kann die Leistung in einigen Fällen verbessern, aber in älteren Node-Versionen zu einem Segfault führen.

poolOptions.threads.isolate

Typ: boolean
Standardwert: true

Isoliert die Umgebung für jede Testdatei.

poolOptions.threads.execArgv*

Typ: string[]
Standardwert: []

Übergibt zusätzliche Argumente an den Node-Prozess in den Threads. Weitere Informationen finden Sie unter Command-line API | Node.js.

WARNING

Vorsicht bei der Verwendung, da einige Optionen den Worker-Prozess zum Absturz bringen können, z. B. --prof, --title. Siehe https://github.com/nodejs/node/issues/41103.

poolOptions.forks

Optionen für den forks-Pool.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      forks: {
        // Forks related options here
      },
    },
  },
});

poolOptions.forks.maxForks*

Typ: number
Standardwert: verfügbare CPU-Kerne

Maximale Anzahl von Forks.

poolOptions.forks.minForks*

Typ: number
Standardwert: verfügbare CPU-Kerne

Minimale Anzahl von Forks.

poolOptions.forks.isolate

Typ: boolean
Standardwert: true

Isoliert die Umgebung für jede Testdatei.

poolOptions.forks.singleFork

Typ: boolean
Standardwert: false

Führt alle Tests in einem einzigen Childprozess mit derselben Umgebung aus. Dadurch wird die integrierte Modulisolierung deaktiviert (Ihr Quellcode oder inline-Code wird weiterhin für jeden Test neu ausgewertet), kann aber die Testleistung verbessern.

WARNING

Auch wenn diese Option erzwingt, dass Tests nacheinander ausgeführt werden, unterscheidet sie sich von Jests --runInBand. Vitest verwendet Childprozesse nicht nur, um Tests parallel auszuführen, sondern auch, um eine Isolierung zu gewährleisten. Durch Deaktivieren dieser Option werden Ihre Tests sequenziell, aber im selben globalen Kontext ausgeführt, sodass Sie die Isolierung selbst bereitstellen müssen.

poolOptions.forks.execArgv*

Typ: string[]
Standardwert: []

Übergibt zusätzliche Argumente an den node-Prozess in den Childprozessen. Weitere Informationen finden Sie unter Command-line API | Node.js.

WARNING

Vorsicht bei der Verwendung, da einige Optionen den Worker-Prozess zum Absturz bringen können, z. B. --prof, --title. Siehe https://github.com/nodejs/node/issues/41103.

poolOptions.vmThreads

Optionen für den vmThreads-Pool.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      vmThreads: {
        // VM threads related options here
      },
    },
  },
});

poolOptions.vmThreads.maxThreads*

Typ: number
Standardwert: verfügbare CPU-Kerne

Maximale Anzahl von Threads. Sie können auch die Umgebungsvariable VITEST_MAX_THREADS verwenden.

poolOptions.vmThreads.minThreads*

Typ: number
Standardwert: verfügbare CPU-Kerne

Minimale Anzahl von Threads. Sie können auch die Umgebungsvariable VITEST_MIN_THREADS verwenden.

poolOptions.vmThreads.memoryLimit*

Typ: string | number
Standardwert: 1 / CPU-Kerne

Gibt die Speicherbegrenzung für Worker-Prozesse an, bevor sie recycelt werden. Dieser Wert hängt stark von Ihrer Umgebung ab, daher ist es besser, ihn manuell anzugeben, anstatt sich auf den Standardwert zu verlassen.

TIP

Die Implementierung basiert auf Jests workerIdleMemoryLimit.

Der Grenzwert kann auf verschiedene Arten angegeben werden. Unabhängig vom Ergebnis wird Math.floor verwendet, um den Wert in eine Ganzzahl umzuwandeln:

<= 1 - Der Wert wird als Prozentsatz des Systemspeichers angenommen. 0,5 setzt also den Speicher-Grenzwert des Worker-Prozesses auf die Hälfte des gesamten Systemspeichers.
\> 1 - Wird als fester Bytewert angenommen. Aufgrund der vorherigen Regel könnten Sie 1,1 verwenden, wenn Sie einen Wert von 1 Byte (ich weiß nicht warum) wollten.
Mit Einheiten
- 50% - Wie oben, ein Prozentsatz des gesamten Systemspeichers
- 100KB, 65MB usw. - Mit Einheiten zur Angabe eines festen Speicher-Grenzwerts.
- K / KB - Kilobyte (x1000)
- KiB - Kibibyte (×1024)
- M / MB - Megabyte
- MiB - Mebibyte
- G / GB - Gigabyte
- GiB - Gibibyte

WARNING

Prozentual basierte Speicher-Grenzwerte funktionieren nicht auf Linux CircleCI Workern, da ein falscher Systemspeicher gemeldet wird.

poolOptions.vmThreads.useAtomics*

Typ: boolean
Standardwert: false

Verwendet Atomics, um Threads zu synchronisieren.

Dies kann die Leistung in einigen Fällen verbessern, aber in älteren Node-Versionen zu einem Segfault führen.

poolOptions.vmThreads.execArgv*

Typ: string[]
Standardwert: []

Übergibt zusätzliche Argumente an den node-Prozess im VM-Context. Weitere Informationen finden Sie unter Command-line API | Node.js.

WARNING

Vorsicht bei der Verwendung, da einige Optionen den Worker-Prozess zum Absturz bringen können, z. B. --prof, --title. Siehe https://github.com/nodejs/node/issues/41103.

poolOptions.vmForks

Optionen für den vmForks-Pool.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      vmForks: {
        // VM forks related options here
      },
    },
  },
});

poolOptions.vmForks.maxForks*

Typ: number
Standardwert: verfügbare CPU-Kerne

Maximale Anzahl von Threads. Sie können auch die Umgebungsvariable VITEST_MAX_FORKS verwenden.

poolOptions.vmForks.minForks*

Typ: number
Standardwert: verfügbare CPU-Kerne

Minimale Anzahl von Threads. Sie können auch die Umgebungsvariable VITEST_MIN_FORKS verwenden.

poolOptions.vmForks.memoryLimit*

Typ: string | number
Standardwert: 1 / CPU-Kerne

poolOptions.vmForks.execArgv*

Typ: string[]
Standardwert: []

Übergibt zusätzliche Argumente an den node-Prozess im VM-Context. Weitere Informationen finden Sie unter Command-line API | Node.js.

WARNING

Vorsicht bei der Verwendung, da einige Optionen den Worker-Prozess zum Absturz bringen können, z. B. --prof, --title. Siehe https://github.com/nodejs/node/issues/41103.

fileParallelism 1.1.0+

Typ: boolean
Standardwert: true
CLI: --no-file-parallelism, --fileParallelism=false

Legt fest, ob Testdateien parallel ausgeführt werden sollen. Wenn auf false gesetzt, werden die Optionen maxWorkers und minWorkers auf 1 gesetzt.

TIP

Diese Option beeinflusst nicht die parallele Ausführung von Tests innerhalb derselben Datei. Verwenden Sie für die parallele Ausführung innerhalb einer Datei die Option concurrent in describe oder eine Konfiguration.

maxWorkers 1.1.0+

Typ: number

Maximale Anzahl an Worker-Prozessen, die Tests ausführen. poolOptions.{threads,vmThreads}.maxThreads/poolOptions.forks.maxForks haben Vorrang.

minWorkers 1.1.0+

Typ: number

Minimale Anzahl an Worker-Prozessen, die Tests ausführen. poolOptions.{threads,vmThreads}.minThreads/poolOptions.forks.minForks haben Vorrang.

testTimeout

Typ: number
Standardwert: 5000
CLI: --test-timeout=5000, --testTimeout=5000

Standard-Timeout für einen einzelnen Test in Millisekunden.

hookTimeout

Typ: number
Standardwert: 10000
CLI: --hook-timeout=10000, --hookTimeout=10000

Standard-Timeout für einen Hook (z.B. beforeEach, afterEach) in Millisekunden.

teardownTimeout*

Typ: number
Standardwert: 10000
CLI: --teardown-timeout=5000, --teardownTimeout=5000

Standard-Timeout in Millisekunden, um auf das Beenden von Vitest zu warten.

silent*

Typ: boolean
Standardwert: false
CLI: --silent, --silent=false

Unterdrückt die Konsolenausgabe von Tests.

setupFiles

Typ: string | string[]

Pfad zu Setup-Dateien. Diese werden vor der Ausführung von Tests in jeder Testdatei ausgeführt.

INFO

Änderungen an Setup-Dateien lösen eine erneute Ausführung aller Tests aus.

Sie können process.env.VITEST_POOL_ID (Integer-ähnlicher String) verwenden, um zwischen verschiedenen Worker-Threads zu unterscheiden.

TIP

Wenn Sie Vitest mit --isolate=false ausführen, wird diese Setup-Datei mehrmals im selben globalen Gültigkeitsbereich ausgeführt. Das bedeutet, dass Sie vor jedem Test auf dasselbe globale Objekt zugreifen können. Stellen Sie sicher, dass Sie nur die notwendigen Operationen durchführen.

Beispiel:

import { config } from '@some-testing-lib';

if (!globalThis.defined) {
  config.plugins = [myCoolPlugin];
  computeHeavyThing();
  globalThis.defined = true;
}

// Hooks werden vor jeder Suite zurückgesetzt.
afterEach(() => {
  cleanup();
});

globalThis.resetBeforeEachTest = true;

globalSetup

Typ: string | string[]

Pfad zu globalen Setup-Dateien, relativ zum Projektstammverzeichnis.

Eine globale Setup-Datei kann entweder die benannten Funktionen setup und teardown oder eine default-Funktion exportieren, die eine Teardown-Funktion zurückgibt (Beispiel).

INFO

Es können mehrere globale Setup-Dateien angegeben werden. Setup- und Teardown-Funktionen werden sequenziell ausgeführt, wobei die Teardown-Funktionen in umgekehrter Reihenfolge aufgerufen werden.

WARNING

Ab Vitest 1.0.0-beta wird das globale Setup nur ausgeführt, wenn mindestens ein Test vorhanden ist. Im Watch-Modus kann das globale Setup nach einer Änderung einer Testdatei erneut gestartet werden. Die Testdatei wartet, bis das globale Setup abgeschlossen ist, bevor sie ausgeführt wird.

Beachten Sie, dass das globale Setup in einem separaten globalen Gültigkeitsbereich ausgeführt wird. Seit Version 1.0.0 können Sie jedoch serialisierbare Daten über die provide-Methode an Tests weitergeben:

globalSetup.jsglobalSetup.tsexample.test.js

export default function setup({ provide }) {
  provide('wsPort', 3000);
}

import type { GlobalSetupContext } from 'vitest/node';

export default function setup({ provide }: GlobalSetupContext) {
  provide('wsPort', 3000);
}

// Sie können auch den Typ `ProvidedContext` erweitern
// um einen typsicheren Zugriff auf die Methoden `provide/inject` zu haben:
declare module 'vitest' {
  export interface ProvidedContext {
    wsPort: number;
  }
}

import { inject } from 'vitest';

inject('wsPort') === 3000;

watchExclude*

Typ: string[]
Standardwert: ['**/node_modules/**', '**/dist/**']
Veraltet: Verwenden Sie server.watch.ignored

Glob-Muster für Dateipfade, die im Watch-Modus ignoriert werden sollen, um eine erneute Ausführung zu verhindern.

forceRerunTriggers*

Typ: string[]
Standardwert: ['**/package.json/**', '**/vitest.config.*/**', '**/vite.config.*/**']

Glob-Muster für Dateipfade, deren Änderungen die erneute Ausführung der gesamten Testsuite auslösen. In Verbindung mit dem Argument --changed wird die gesamte Testsuite ausgeführt, wenn der Trigger im Git-Diff gefunden wird.

Nützlich beim Testen von CLI-Befehlen, da Vite keinen Modulgraphen erstellen kann:

test('execute a script', async () => {
  // Vitest kann diesen Test nicht erneut ausführen, wenn sich der Inhalt von `dist/index.js` ändert
  await execa('node', ['dist/index.js']);
});

TIP

Stellen Sie sicher, dass Ihre Dateien nicht durch watchExclude ausgeschlossen werden.

coverage*

Sie können v8, istanbul oder eine benutzerdefinierte Coverage-Lösung zur Erfassung der Testabdeckung verwenden.

Coverage-Optionen können über die CLI mit Punktnotation angegeben werden:

npx vitest --coverage.enabled --coverage.provider=istanbul --coverage.all

WARNING

Wenn Sie Coverage-Optionen mit Punktnotation verwenden, vergessen Sie nicht, --coverage.enabled anzugeben. Geben Sie in diesem Fall keine einzelne --coverage-Option an.

coverage.provider

Typ: 'v8' | 'istanbul' | 'custom'
Standardwert: 'v8'
CLI: --coverage.provider=<provider>

Wählt das Tool zur Erfassung der Testabdeckung aus.

coverage.enabled

Typ: boolean
Standardwert: false
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.enabled, --coverage.enabled=false

Aktiviert die Erfassung der Testabdeckung. Kann durch die CLI-Option --coverage überschrieben werden.

coverage.include

Typ: string[]
Standardwert: ['**']
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.include=<path>, --coverage.include=<path1> --coverage.include=<path2>

Liste der Dateien, die in die Testabdeckung einbezogen werden sollen, angegeben als Glob-Muster.

coverage.extension

Typ: string | string[]
Standardwert: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.cts', '.tsx', '.jsx', '.vue', '.svelte', '.marko']
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.extension=<extension>, --coverage.extension=<extension1> --coverage.extension=<extension2>

coverage.exclude

Typ: string[]
Standardwert:

[
  'coverage/**',
  'dist/**',
  '**/[.]**',
  'packages/*/test?(s)/**',
  '**/*.d.ts',
  '**/virtual:*',
  '**/__x00__*',
  '**/\x00*',
  'cypress/**',
  'test?(s)/**',
  'test?(-*).?(c|m)[jt]s?(x)',
  '**/*{.,-}{test,spec}?(-d).?(c|m)[jt]s?(x)',
  '**/__tests__/**',
  '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build}.config.*',
  '**/vitest.{workspace,projects}.[jt]s?(on)',
  '**/.{eslint,mocha,prettier}rc.{?(c|m)js,yml}',
];

Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.exclude=<path>, --coverage.exclude=<path1> --coverage.exclude=<path2>

Liste der Dateien, die von der Testabdeckung ausgeschlossen werden sollen, angegeben als Glob-Muster.

Diese Option ersetzt alle Standardoptionen. Erweitern Sie die Standardoptionen, wenn Sie neue Muster zum Ignorieren hinzufügen möchten:

import { coverageConfigDefaults, defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    coverage: {
      exclude: ['**/custom-pattern/**', ...coverageConfigDefaults.exclude],
    },
  },
});

coverage.all

Typ: boolean
Standardwert: true (seit Vitest 1.0.0)
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.all, --coverage.all=false

Legt fest, ob alle Dateien, einschließlich der ungetesteten, in den Bericht aufgenommen werden sollen.

coverage.clean

Typ: boolean
Standardwert: true
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.clean, --coverage.clean=false

Bereinigt die Coverage-Ergebnisse vor der Testausführung.

coverage.cleanOnRerun

Typ: boolean
Standardwert: true
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.cleanOnRerun, --coverage.cleanOnRerun=false

Löscht den Coverage-Bericht bei erneuter Ausführung im Watch-Modus.

coverage.reportsDirectory

Typ: string
Standardwert: './coverage'
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.reportsDirectory=<path>

WARNING

Vitest löscht dieses Verzeichnis vor der Testausführung, wenn coverage.clean aktiviert ist (Standardwert).

Verzeichnis, in das der Coverage-Bericht geschrieben wird.

Um den Coverage-Bericht in der Ausgabe des HTML-Reporters anzuzeigen, muss diese Option als Unterverzeichnis des HTML-Berichtsverzeichnisses festgelegt werden (z. B. ./html/coverage).

coverage.reporter

Typ: string | string[] | [string, {}][]
Standardwert: ['text', 'html', 'clover', 'json']
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.reporter=<reporter>, --coverage.reporter=<reporter1> --coverage.reporter=<reporter2>

Zu verwendende Coverage-Reporter. Eine detaillierte Liste aller Reporter finden Sie in der Istanbul-Dokumentation. Details zu reporterspezifischen Optionen finden Sie unter @types/istanbul-reporter.

Der Reporter kann in drei verschiedene Typen unterteilt werden:

Ein einzelner Reporter: { reporter: 'html' }
Mehrere Reporter ohne Optionen: { reporter: ['html', 'json'] }

Ein einzelner oder mehrere Reporter mit Reporteroptionen:

{
  reporter: [
    ['lcov', { projectRoot: './src' }],
    ['json', { file: 'coverage.json' }],
    ['text'],
  ];
}

Seit Vitest 1.2.0 können Sie auch benutzerdefinierte Coverage-Reporter angeben. Weitere Informationen finden Sie unter Guide - Custom Coverage Reporter.

{
  reporter: [
    // Reporter über den Namen des NPM-Pakets angeben
    '@vitest/custom-coverage-reporter',
    ['@vitest/custom-coverage-reporter', { someOption: true }],

    // Reporter über den lokalen Pfad angeben
    '/absolute/path/to/custom-reporter.cjs',
    ['/absolute/path/to/custom-reporter.cjs', { someOption: true }],
  ];
}

Seit Vitest 0.31.0 können Sie Ihren Coverage-Bericht in der Vitest-UI überprüfen: Weitere Informationen finden Sie unter Vitest UI Coverage.

coverage.reportOnFailure 0.31.2+

Typ: boolean
Standardwert: false (seit Vitest 0.34.0)
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.reportOnFailure, --coverage.reportOnFailure=false

Generiert einen Coverage-Bericht, auch wenn Tests fehlschlagen.

coverage.allowExternal

Typ: boolean
Standardwert: false
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.allowExternal, --coverage.allowExternal=false

Sammelt die Coverage von Dateien außerhalb des Projekt-root-Verzeichnisses.

coverage.skipFull

Typ: boolean
Standardwert: false
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.skipFull, --coverage.skipFull=false

Blendet Dateien mit 100 % Anweisungs-, Zweig- und Funktionsabdeckung aus.

coverage.thresholds

Optionen für Coverage-Schwellenwerte

coverage.thresholds.lines

Typ: number
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.thresholds.lines=<number>

Globaler Schwellenwert für Zeilenabdeckung. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.thresholds.functions

Typ: number
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.thresholds.functions=<number>

Globaler Schwellenwert für Funktionsabdeckung. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.thresholds.branches

Typ: number
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.thresholds.branches=<number>

Globaler Schwellenwert für Verzweigungsabdeckung. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.thresholds.statements

Typ: number
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.thresholds.statements=<number>

Globaler Schwellenwert für Anweisungsabdeckung. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.thresholds.perFile

Typ: boolean
Standardwert: false
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.thresholds.perFile, --coverage.thresholds.perFile=false

Überprüft Schwellenwerte pro Datei.

coverage.thresholds.autoUpdate

Typ: boolean
Standardwert: false
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.thresholds.autoUpdate=<boolean>

Aktualisiert alle Schwellenwerte (lines, functions, branches und statements) in der Konfigurationsdatei, wenn die aktuelle Coverage über den konfigurierten Schwellenwerten liegt. Diese Option hilft, Schwellenwerte beizubehalten, wenn die Coverage verbessert wird.

coverage.thresholds.100

Typ: boolean
Standardwert: false
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.thresholds.100, --coverage.thresholds.100=false

Legt globale Schwellenwerte auf 100 % fest. Abkürzung für --coverage.thresholds.lines 100 --coverage.thresholds.functions 100 --coverage.thresholds.branches 100 --coverage.thresholds.statements 100.

coverage.thresholds[glob-pattern]

Typ: { statements?: number functions?: number branches?: number lines?: number }
Standardwert: undefined
Verfügbar für Provider: 'v8' | 'istanbul'

Legt Schwellenwerte für Dateien fest, die dem Glob-Muster entsprechen.

{
  coverage: {
    thresholds: {
      // Schwellenwerte für alle Dateien
      functions: 95,
      branches: 70,

      // Schwellenwerte für übereinstimmende Glob-Muster
      'src/utils/**.ts': {
        statements: 95,
        functions: 90,
        branches: 85,
        lines: 80,
      },

      // Dateien, die diesem Muster entsprechen, haben nur Zeilenschwellenwerte festgelegt.
      // Globale Schwellenwerte werden nicht vererbt.
      '**/math.ts': {
        lines: 100,
      }
    }
  }
}

coverage.ignoreEmptyLines

Typ: boolean
Standardwert: false
Verfügbar für Provider: 'v8'
CLI: --coverage.ignoreEmptyLines=<boolean>

Ignoriert leere Zeilen, Kommentare und anderen Nicht-Laufzeit-Code wie Typescript-Typdefinitionen.

Diese Option funktioniert nur, wenn der verwendete Compiler Kommentare und anderen Nicht-Laufzeit-Code aus dem transpilierten Code entfernt. Standardmäßig verwendet Vite ESBuild, das Kommentare und Typescript-Typen aus .ts-, .tsx- und .jsx-Dateien entfernt.

Wenn Sie ESBuild auch auf andere Dateien anwenden möchten, definieren Sie diese in den esbuild-Optionen:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  esbuild: {
    // Transpiliert alle Dateien mit ESBuild, um Kommentare aus der Code-Coverage zu entfernen.
    // Erforderlich, damit `test.coverage.ignoreEmptyLines` funktioniert:
    include: ['**/*.js', '**/*.jsx', '**/*.mjs', '**/*.ts', '**/*.tsx'],
  },
  test: {
    coverage: {
      provider: 'v8',
      ignoreEmptyLines: true,
    },
  },
});

coverage.ignoreClassMethods

Typ: string[]
Standardwert: []
Verfügbar für Provider: 'istanbul'
CLI: --coverage.ignoreClassMethods=<method>

Setzen Sie dies auf ein Array von Klassennamen, deren Methoden für die Coverage ignoriert werden sollen. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.watermarks

Typ:

{
  statements?: [number, number],
  functions?: [number, number],
  branches?: [number, number],
  lines?: [number, number]
}

Standardwert:

{
  statements: [50, 80],
  functions: [50, 80],
  branches: [50, 80],
  lines: [50, 80]
}

Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.watermarks.statements=50,80, --coverage.watermarks.branches=50,80

Grenzwerte für Anweisungen, Zeilen, Verzweigungen und Funktionen. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.processingConcurrency

Typ: boolean
Standardwert: Math.min(20, os.availableParallelism?.() ?? os.cpus().length)
Verfügbar für Provider: 'v8' | 'istanbul'
CLI: --coverage.processingConcurrency=<number>

Parallelitätslimit, das bei der Verarbeitung der Coverage-Ergebnisse verwendet wird.

coverage.customProviderModule

Typ: string
Verfügbar für Provider: 'custom'
CLI: --coverage.customProviderModule=<path or module name>

Gibt den Modulnamen oder Pfad für das benutzerdefinierte Coverage-Provider-Modul an. Weitere Informationen finden Sie unter Guide - Custom Coverage Provider.

testNamePattern*

Typ: string | RegExp
CLI: -t <pattern>, --testNamePattern=<pattern>, --test-name-pattern=<pattern>

Führt Tests aus, deren vollständiger Name dem angegebenen Muster entspricht. Wenn Sie OnlyRunThis zu diesem Attribut hinzufügen, werden Tests übersprungen, die das Wort OnlyRunThis nicht im Testnamen enthalten.

import { expect, test } from 'vitest';

// wird ausgeführt
test('OnlyRunThis', () => {
  expect(true).toBe(true);
});

// wird übersprungen
test('doNotRun', () => {
  expect(true).toBe(true);
});

open*

Typ: boolean
Standardwert: !process.env.CI
CLI: --open, --open=false

Öffnet die Vitest-Benutzeroberfläche (in Entwicklung).

api

Typ: boolean | number
Standardwert: false
CLI: --api, --api.port, --api.host, --api.strictPort

Startet einen Server auf einem Port und stellt eine API bereit. Wenn auf true gesetzt, ist der Standardport 51204.

browser 0.29.4+

Typ: { enabled?, name?, provider?, headless?, api?, slowHijackESM? }
Standardwert: { enabled: false, headless: process.env.CI, api: 63315 }
CLI: --browser, --browser=<name>, --browser.name=chrome --browser.headless

Führt Vitest-Tests in einem Browser aus. Standardmäßig wird WebdriverIO verwendet, um Tests auszuführen. Dies kann jedoch mit der Option browser.provider angepasst werden.

HINWEIS

Weitere Informationen zum Testen in einem echten Browser finden Sie auf der Anleitungsseite.

WARNING

Dies ist eine experimentelle Funktion. Breaking Changes müssen sich möglicherweise nicht an SemVer halten. Bitte fixieren Sie die Version von Vitest, wenn Sie diese Funktion verwenden.

browser.enabled

Typ: boolean
Standardwert: false
CLI: --browser, --browser.enabled=false

Aktiviert die Ausführung aller Tests in einem Browser. Kann mit der Option poolMatchGlobs überschrieben werden.

browser.name

Typ: string
CLI: --browser=safari

Führt alle Tests in einem bestimmten Browser aus. Mögliche Optionen in verschiedenen Providern:

webdriverio: firefox, chrome, edge, safari
playwright: firefox, webkit, chromium
custom: Eine beliebige Zeichenkette, die an den Provider übergeben wird.

browser.headless

Typ: boolean
Standardwert: process.env.CI
CLI: --browser.headless, --browser.headless=false

Führt den Browser im Headless-Modus aus. Wenn Vitest in einer CI-Umgebung ausgeführt wird, ist dies standardmäßig aktiviert.

browser.isolate

Typ: boolean
Standardwert: true
CLI: --browser.isolate, --browser.isolate=false

Führt jeden Test in einem separaten Iframe aus.

browser.fileParallelism 1.3.0+

Typ: boolean
Standardwert: derselbe wie fileParallelism
CLI: --browser.fileParallelism=false

Erstellt alle Test-IFrames gleichzeitig, sodass sie parallel ausgeführt werden können.

Dies macht die Verwendung interaktiver APIs (wie Klicken oder Hovern) unmöglich, da mehrere IFrames gleichzeitig auf dem Bildschirm angezeigt werden. Wenn Ihre Tests diese APIs jedoch nicht benötigen, kann die parallele Ausführung deutlich schneller sein.

TIP

Wenn Sie die Isolation über browser.isolate=false deaktiviert haben, werden Ihre Testdateien aufgrund der Funktionsweise des Test-Runners weiterhin nacheinander ausgeführt.

browser.api

Typ: number | { port?, strictPort?, host? }
Standardwert: 63315
CLI: --browser.api=63315, --browser.api.port=1234, --browser.api.host=example.com

Konfiguriert Optionen für den Vite-Server, der Code im Browser bereitstellt. Hat keinen Einfluss auf die Option test.api.

browser.provider

Typ: 'webdriverio' | 'playwright' | string
Standardwert: 'webdriverio'
CLI: --browser.provider=playwright

Pfad zu einem Provider, der beim Ausführen von Browser-Tests verwendet wird. Vitest bietet zwei Provider an: webdriverio (Standard) und playwright. Benutzerdefinierte Provider müssen als default-Export exportiert werden und folgendes Format aufweisen:

export interface BrowserProvider {
  name: string;
  getSupportedBrowsers: () => readonly string[];
  initialize: (
    ctx: Vitest,
    options: { browser: string; options?: BrowserProviderOptions }
  ) => Awaitable<void>;
  openPage: (url: string) => Awaitable<void>;
  close: () => Awaitable<void>;
}

WARNING

Dies ist eine erweiterte API für Bibliotheksautoren. Wenn Sie nur Tests in einem Browser ausführen müssen, verwenden Sie die Option browser.

browser.providerOptions 1.0.0+

Typ: BrowserProviderOptions

Optionen, die beim Aufruf von provider.initialize an den Provider übergeben werden.

export default defineConfig({
  test: {
    browser: {
      providerOptions: {
        launch: {
          devtools: true,
        },
      },
    },
  },
});

TIP

Um eine bessere Typsicherheit bei der Verwendung von integrierten Providern zu gewährleisten, können Sie eines dieser Typen (für den von Ihnen verwendeten Provider) zum Feld compilerOptions.types Ihrer tsconfig hinzufügen:

json

{
  "compilerOptions": {
    "types": [
      "@vitest/browser/providers/webdriverio",
      "@vitest/browser/providers/playwright"
    ]
  }
}

browser.slowHijackESM 0.31.0+

Typ: boolean
Standardwert: false

Bei der Ausführung von Tests in Node.js kann Vitest seine eigene Modulauflösung verwenden, um Module einfach mit der vi.mock-Syntax zu mocken. Es ist jedoch nicht so einfach, die ES-Modulauflösung im Browser zu replizieren, daher müssen wir Ihre Quelldateien transformieren, bevor der Browser sie verwenden kann.

Diese Option hat keine Auswirkungen auf Tests, die in Node.js ausgeführt werden.

Wenn Sie ES-Module mit vi.spyOn überwachen müssen, können Sie diese experimentelle Funktion aktivieren, um das Überwachen von Modulexporten zu ermöglichen.

browser.indexScripts 1.6.0+

Typ: BrowserScript[]
Standardwert: []

Benutzerdefinierte Skripte, die in das Index-HTML injiziert werden sollen, bevor die Test-IFrames initialisiert werden. Dieses HTML-Dokument richtet nur IFrames ein und importiert nicht tatsächlich Ihren Code.

Das Skript src und content werden von Vite-Plugins verarbeitet. Das Skript sollte in folgender Form bereitgestellt werden:

export interface BrowserScript {
  /**
   * If "content" is provided and type is "module", this will be its identifier.
   *
   * If you are using TypeScript, you can add `.ts` extension here for example.
   * @default `injected-${index}.js`
   */
  id?: string;
  /**
   * JavaScript content to be injected. This string is processed by Vite plugins if type is "module".
   *
   * You can use `id` to give Vite a hint about the file extension.
   */
  content?: string;
  /**
   * Path to the script. This value is resolved by Vite so it can be a node module or a file path.
   */
  src?: string;
  /**
   * If the script should be loaded asynchronously.
   */
  async?: boolean;
  /**
   * Script type.
   * @default 'module'
   */
  type?: string;
}

browser.testerScripts 1.6.0+

Typ: BrowserScript[]
Standardwert: []

Benutzerdefinierte Skripte, die vor der Initialisierung der Testumgebung in das Tester-HTML injiziert werden sollen. Dies ist nützlich, um Polyfills zu injizieren, die für die Vitest-Browserimplementierung erforderlich sind. Es wird empfohlen, in fast allen Fällen setupFiles anstelle dessen zu verwenden.

Das Skript src und content werden von Vite-Plugins verarbeitet.

clearMocks

Typ: boolean
Standardwert: false

Ruft vor jedem Test .mockClear() für alle Spione auf. Dadurch wird der Mock-Verlauf gelöscht, aber die Implementierung nicht auf die Standardeinstellung zurückgesetzt.

mockReset

Typ: boolean
Standardwert: false

Ruft vor jedem Test .mockReset() für alle Spione auf. Dadurch wird der Mock-Verlauf gelöscht und die Implementierung auf eine leere Funktion zurückgesetzt (gibt undefined zurück).

restoreMocks

Typ: boolean
Standardwert: false

Ruft vor jedem Test .mockRestore() für alle Spione auf. Dadurch wird der Mock-Verlauf gelöscht und die Implementierung auf die ursprüngliche zurückgesetzt.

unstubEnvs 0.26.0+

Typ: boolean
Standardwert: false

Ruft vor jedem Test vi.unstubAllEnvs auf.

unstubGlobals 0.26.0+

Typ: boolean
Standardwert: false

Ruft vor jedem Test vi.unstubAllGlobals auf.

testTransformMode 0.34.0+

Typ: { web?, ssr? }

Bestimmt die Transformationsmethode für alle Module, die innerhalb eines Tests importiert werden, der mit dem Glob-Muster übereinstimmt. Standardmäßig wird die Umgebung verwendet. Beispielsweise verarbeiten Tests mit JSDOM-Umgebung alle Dateien mit dem Flag ssr: false und Tests mit Node-Umgebung alle Module mit ssr: true.

testTransformMode.ssr

Typ: string[]
Standardwert: []

Verwendet die Server-Side-Rendering-Transformationspipeline für alle Module innerhalb der angegebenen Tests.
Vite-Plugins erhalten das Flag ssr: true, wenn diese Dateien verarbeitet werden.

testTransformMode.web

Typ: string[]
Standardwert: []

Führt zuerst eine normale Transformationspipeline (für den Browser) und anschließend ein SSR-Rewriting durch, um den Code in Node auszuführen.
Vite-Plugins erhalten das Flag ssr: false, wenn diese Dateien verarbeitet werden.

snapshotFormat*

Typ: PrettyFormatOptions

Formatoptionen für Snapshot-Tests. Diese Optionen werden an pretty-format übergeben.

TIP

Beachten Sie, dass das Feld plugins in diesem Objekt ignoriert wird.

Wenn Sie den Snapshot-Serialisierer über Pretty-Format-Plugins erweitern müssen, verwenden Sie bitte die API expect.addSnapshotSerializer oder die Option snapshotSerializers.

snapshotSerializers* 1.3.0+

Typ: string[]
Standardwert: []

Eine Liste von Pfaden zu Snapshot-Serialisierer-Modulen für Snapshot-Tests. Nützlich, um benutzerdefinierte Snapshot-Serialisierer hinzuzufügen. Weitere Informationen finden Sie unter Benutzerdefinierter Serialisierer.

resolveSnapshotPath*

Typ: (testPath: string, snapExtension: string) => string
Standardwert: Speichert Snapshot-Dateien im Verzeichnis __snapshots__

Überschreibt den Standard-Snapshot-Pfad. Um beispielsweise Snapshots neben Testdateien zu speichern:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    resolveSnapshotPath: (testPath, snapExtension) => testPath + snapExtension,
  },
});

allowOnly

Typ: boolean
Standardwert: !process.env.CI
CLI: --allowOnly, --allowOnly=false

Erlaubt die Ausführung von Tests und Suiten, die mit only markiert sind.

dangerouslyIgnoreUnhandledErrors*

Typ: boolean
Standardwert: false
CLI: --dangerouslyIgnoreUnhandledErrors --dangerouslyIgnoreUnhandledErrors=false

Ignoriert alle unbehandelten Fehler, die auftreten. Achtung: Dies sollte nur für Debugging-Zwecke verwendet werden.

passWithNoTests*

Typ: boolean
Standardwert: false
CLI: --passWithNoTests, --passWithNoTests=false

Verhindert, dass Vitest einen Fehler ausgibt, wenn keine Tests gefunden werden.

logHeapUsage

Typ: boolean
Standardwert: false
CLI: --logHeapUsage, --logHeapUsage=false

Zeigt die Heap-Nutzung nach jedem Test an. Nützlich zum Debuggen von Speicherlecks.

css

Typ: boolean | { include?, exclude?, modules? }

Konfiguriert, ob CSS verarbeitet werden soll. Wenn ausgeschlossen, werden CSS-Dateien durch leere Strings ersetzt, um die weitere Verarbeitung zu verhindern. CSS-Module geben einen Proxy zurück, um die Laufzeit nicht zu beeinträchtigen.

css.include

Typ: RegExp | RegExp[]
Standardwert: []

RegExp-Muster für Dateien, die tatsächliches CSS zurückgeben und von der Vite-Pipeline verarbeitet werden sollen.

TIP

Um alle CSS-Dateien zu verarbeiten, verwenden Sie /.+/.

css.exclude

Typ: RegExp | RegExp[]
Standardwert: []

RegExp-Muster für Dateien, die eine leere CSS-Datei zurückgeben.

css.modules

Typ: { classNameStrategy? }
Standardwert: {}

css.modules.classNameStrategy

Typ: 'stable' | 'scoped' | 'non-scoped'
Standardwert: 'stable'

Wenn Sie sich entscheiden, CSS-Dateien zu verarbeiten, können Sie festlegen, ob Klassennamen innerhalb von CSS-Modulen einen Scope haben sollen. Sie können eine der folgenden Optionen wählen:

stable: Klassennamen werden als _${name}_${hashedFilename} generiert. Das bedeutet, dass der generierte Name gleich bleibt, solange sich der CSS-Inhalt nicht ändert. Er ändert sich jedoch, wenn der Dateiname geändert oder die Datei in einen anderen Ordner verschoben wird. Diese Einstellung ist nützlich, wenn Sie die Snapshot-Funktion verwenden.
scoped: Klassennamen werden wie gewohnt generiert, wobei die Methode css.modules.generateScopeName berücksichtigt wird, falls vorhanden, und die CSS-Verarbeitung aktiviert ist. Standardmäßig wird der Klassenname als _${name}_${hash} generiert, wobei der Hash sowohl den Dateinamen als auch den Inhalt der Datei berücksichtigt.
non-scoped: Klassennamen werden nicht gehasht.

WARNING

Standardmäßig exportiert Vitest einen Proxy, der die CSS-Module-Verarbeitung umgeht. Wenn Ihre Klassen auf CSS-Eigenschaften angewiesen sind, müssen Sie die CSS-Verarbeitung mithilfe der Option include aktivieren.

maxConcurrency

Typ: number
Standardwert: 5
CLI: --max-concurrency=10, --maxConcurrency=10

Die maximale Anzahl an Tests, die gleichzeitig mit test.concurrent ausgeführt werden dürfen.

Tests, die dieses Limit überschreiten, werden in eine Warteschlange gestellt und ausgeführt, sobald ein Ausführungsplatz frei wird.

cache*

Typ: false
CLI: --no-cache, --cache=false

Verwenden Sie diese Option, um die Cache-Funktion zu deaktivieren. Vitest speichert Testergebnisse im Cache, um zuerst die zeitaufwändigsten und fehlgeschlagenen Tests auszuführen.

sequence

Typ: { Sequencer?, Shuffle?, Seed?, Hooks?, SetupFiles? }

Optionen zur Steuerung der Testreihenfolge.

Sie können Sequenzoptionen über die CLI mit Punktnotation festlegen:

npx vitest --sequence.shuffle --sequence.seed=1000

sequence.sequencer*

Typ: TestSequencerConstructor
Standardwert: BaseSequencer

Eine benutzerdefinierte Klasse, die Methoden für Sharding und Sortierung definiert. Sie können BaseSequencer von vitest/node erweitern, wenn Sie nur eine der Methoden sort oder shard anpassen müssen. Beide Methoden sollten jedoch vorhanden sein.

Sharding findet vor der Sortierung statt und nur, wenn die Option --shard angegeben ist.

sequence.shuffle

Typ: boolean | { Files?, Tests? }
Standardwert: false
CLI: --sequence.shuffle, --sequence.shuffle=false

Um Dateien und Tests in zufälliger Reihenfolge auszuführen, können Sie diese Option oder das CLI-Argument --sequence.shuffle aktivieren.

Vitest verwendet normalerweise den Cache, um Tests zu sortieren und dadurch lang laufende Tests früher zu starten, was die Testausführung beschleunigt. Wenn Ihre Dateien und Tests in zufälliger Reihenfolge ausgeführt werden, entfällt diese Leistungsverbesserung. Es kann jedoch nützlich sein, um Tests zu identifizieren, die unbeabsichtigt von einem vorherigen Lauf abhängen.

sequence.shuffle.files 1.4.0+

Typ: boolean
Standardwert: false
CLI: --sequence.shuffle.files, --sequence.shuffle.files=false

Legt fest, ob die Dateien in zufälliger Reihenfolge angeordnet werden sollen. Beachten Sie, dass lang laufende Tests nicht priorisiert werden, wenn diese Option aktiviert ist.

sequence.shuffle.tests 1.4.0+

Typ: boolean
Standardwert: false
CLI: --sequence.shuffle.tests, --sequence.shuffle.tests=false

Legt fest, ob die Tests in zufälliger Reihenfolge angeordnet werden sollen.

sequence.concurrent 0.32.2+

Typ: boolean
Standardwert: false
CLI: --sequence.concurrent, --sequence.concurrent=false

Um Tests parallel auszuführen, können Sie diese Option oder das CLI-Argument --sequence.concurrent aktivieren.

sequence.seed*

Typ: number
Standardwert: Date.now()
CLI: --sequence.seed=1000

Legt den Zufalls-Seed fest, wenn die Tests in zufälliger Reihenfolge ausgeführt werden.

sequence.hooks

Typ: 'stack' | 'list' | 'parallel'
Standardwert: 'parallel'
CLI: --sequence.hooks=<value>

Legt die Ausführungsreihenfolge der Hooks fest.

stack ordnet "after"-Hooks in umgekehrter Reihenfolge an, "before"-Hooks werden in der Definitionsreihenfolge ausgeführt.
list führt alle Hooks in der Definitionsreihenfolge aus.
parallel führt Hooks innerhalb einer einzelnen Gruppe parallel aus (Hooks in übergeordneten Suites werden weiterhin vor den Hooks der aktuellen Suite ausgeführt).

TIP

Diese Option hat keinen Einfluss auf onTestFinished. Sie wird immer in umgekehrter Reihenfolge aufgerufen.

sequence.setupFiles 0.29.3+

Typ: 'list' | 'parallel'
Standardwert: 'parallel'
CLI: --sequence.setupFiles=<value>

Legt die Ausführungsreihenfolge der Setup-Dateien fest.

list führt Setup-Dateien in der Definitionsreihenfolge aus.
parallel führt Setup-Dateien parallel aus.

typecheck

Optionen zur Konfiguration der Typprüfungs-Testumgebung.

typecheck.enabled 1.0.0+

Typ: boolean
Standardwert: false
CLI: --typecheck, --typecheck.enabled

Aktiviert die Typprüfung zusätzlich zu Ihren regulären Tests.

typecheck.only 1.0.0+

Typ: boolean
Standardwert: false
CLI: --typecheck.only

Führt nur Typprüfungs-Tests aus, wenn die Typprüfung aktiviert ist. Bei Verwendung der CLI wird die Typprüfung durch diese Option automatisch aktiviert.

typecheck.checker

Typ: 'tsc' | 'vue-tsc' | string
Standardwert: tsc

Legt fest, welches Tool für die Typprüfung verwendet werden soll. Vitest erzeugt einen Prozess mit bestimmten Parametern zur einfacheren Analyse, abhängig vom Typ. Der Checker sollte das gleiche Ausgabeformat wie tsc implementieren.

Sie müssen ein Paket installieren, um den Typechecker zu verwenden:

tsc erfordert das typescript-Paket.
vue-tsc erfordert das vue-tsc-Paket.

Sie können auch einen Pfad zu einer benutzerdefinierten Binärdatei oder einem Befehlsnamen übergeben, der die gleiche Ausgabe wie tsc --noEmit --pretty false erzeugt.

typecheck.include

Typ: string[]
Standardwert: ['**/*.{test,spec}-d.?(c|m)[jt]s?(x)']

Glob-Muster für Dateien, die als Testdateien behandelt werden sollen.

typecheck.exclude

Typ: string[]
Standardwert: ['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**']

Glob-Muster für Dateien, die nicht als Testdateien behandelt werden sollen.

typecheck.allowJs

Typ: boolean
Standardwert: false

Überprüft JS-Dateien, die den Kommentar @ts-check enthalten. Wenn dies in der tsconfig-Datei aktiviert ist, wird diese Einstellung nicht überschrieben.

typecheck.ignoreSourceErrors

Typ: boolean
Standardwert: false

Verhindert, dass Vitest fehlschlägt, wenn Fehler außerhalb der Testdateien gefunden werden. Dadurch werden Fehler, die nicht Test-bezogen sind, nicht angezeigt.

Standardmäßig schlägt die Testsuite fehl, wenn Vitest einen Fehler im Quellcode findet.

typecheck.tsconfig

Typ: string
Standardwert: versucht, die nächstgelegene tsconfig.json zu finden

Pfad zu einer benutzerdefinierten tsconfig-Datei, relativ zum Projektstammverzeichnis.

slowTestThreshold*

Typ: number
Standardwert: 300
CLI: --slow-test-threshold=<number>, --slowTestThreshold=<number>

Die Anzahl der Millisekunden, nach der ein Test als langsam gilt und in den Ergebnissen entsprechend gekennzeichnet wird.

chaiConfig 0.30.0+

Typ: { includeStack?, showDiff?, truncateThreshold? }
Standardwert: { includeStack: false, showDiff: true, truncateThreshold: 40 }

Entspricht der Chai-Konfiguration.

chaiConfig.includeStack

Typ: boolean
Standardwert: false

Beeinflusst, ob ein Stacktrace in der Fehlermeldung der Assertion enthalten ist. Der Standardwert false unterdrückt den Stacktrace in der Fehlermeldung.

chaiConfig.showDiff

Typ: boolean
Standardwert: true

Beeinflusst, ob das showDiff-Flag in den ausgelösten AssertionErrors enthalten sein soll. false ist immer false; true ist true, wenn die Assertion die Anzeige eines Diffs angefordert hat.

chaiConfig.truncateThreshold

Typ: number
Standardwert: 40

Legt die maximale Länge für tatsächliche und erwartete Werte in Assertionsfehlern fest. Wenn dieser Wert überschritten wird, z. B. bei großen Datenstrukturen, wird der Wert durch etwas wie [ Array(3) ] oder { Object (prop1, prop2) } ersetzt. Setzen Sie den Wert auf 0, um das Abschneiden vollständig zu deaktivieren.

Diese Konfigurationsoption beeinflusst das Abschneiden von Werten in test.each-Titeln sowie innerhalb der Assertionsfehlermeldung.

bail 0.31.0+

Typ: number
Standardwert: 0
CLI: --bail=<value>

Beendet die Testausführung, sobald eine bestimmte Anzahl von Tests fehlgeschlagen ist.

Standardmäßig führt Vitest alle Testfälle aus, auch wenn einige fehlschlagen. Dies ist möglicherweise unerwünscht für CI-Builds, bei denen nur vollständig erfolgreiche Builds von Interesse sind und die Testausführung bei Auftreten von Fehlern so früh wie möglich beendet werden soll. Die Option bail kann verwendet werden, um CI-Ausführungen zu beschleunigen, indem verhindert wird, dass weitere Tests nach dem Auftreten von Fehlern ausgeführt werden.

retry 0.32.3+

Typ: number
Standardwert: 0
CLI: --retry=<value>

Wiederholt den Test eine bestimmte Anzahl von Malen, falls er fehlschlägt.

onConsoleLog*

Typ: (log: string, type: 'stdout' | 'stderr') => boolean | void

Benutzerdefinierter Handler für console.log-Ausgaben in Tests. Wenn false zurückgegeben wird, gibt Vitest den Log nicht in der Konsole aus.

Kann nützlich sein, um Logs von Bibliotheken Dritter herauszufiltern.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    onConsoleLog(log: string, type: 'stdout' | 'stderr'): boolean | void {
      return !(log === 'message from third party library' && type === 'stdout');
    },
  },
});

onStackTrace* 1.0.0+

Typ: (error: Error, frame: ParsedStack) => boolean | void

Wendet eine Filterfunktion auf jeden Frame jedes Stacktraces an, wenn Fehler behandelt werden. Das erste Argument, error, ist ein Objekt mit den gleichen Eigenschaften wie ein Standard-Error, jedoch keine tatsächliche Instanz.

Kann nützlich sein, um Stacktrace-Frames von Bibliotheken Dritter herauszufiltern.

import type { ParsedStack } from 'vitest';
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    onStackTrace(error: Error, { file }: ParsedStack): boolean | void {
      // Wenn wir auf einen ReferenceError gestoßen sind, zeigen wir den gesamten Stack.
      if (error.name === 'ReferenceError') return;

      // Lehne alle Frames von Drittanbieterbibliotheken ab.
      if (file.includes('node_modules')) return false;
    },
  },
});

diff 0.34.5+

Typ: string
CLI: --diff=<value>

Pfad zu einer Diff-Konfigurationsdatei, die zur Generierung der Diff-Ansicht verwendet wird. Nützlich, um die Diff-Anzeige anzupassen.

vitest.diff.tsvitest.config.js

import type { DiffOptions } from 'vitest';
import c from 'picocolors';

export default {
  aIndicator: c.bold('--'),
  bIndicator: c.bold('++'),
  omitAnnotationLines: true,
} satisfies DiffOptions;

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    diff: './vitest.diff.ts',
  },
});

diff.truncateThreshold

Typ: number
Standardwert: 0

Die maximale Länge des anzuzeigenden Diff-Ergebnisses. Diffs, die diese Länge überschreiten, werden abgeschnitten. Das Abschneiden ist bei einem Standardwert von 0 deaktiviert.

diff.truncateAnnotation

Typ: string
Standardwert: '... Diff result is truncated'

Anmerkung, die am Ende des Diff-Ergebnisses angezeigt wird, wenn dieses abgeschnitten wurde.

diff.truncateAnnotationColor

Typ: DiffOptionsColor = (arg: string) => string
Standardwert: noColor = (string: string): string => string

Farbe der Abschneide-Anmerkung; standardmäßig wird keine Farbe verwendet.

fakeTimers

Typ: FakeTimerInstallOpts

Optionen, die Vitest an @sinon/fake-timers weitergibt, wenn vi.useFakeTimers() verwendet wird.

fakeTimers.now

Typ: number | Date
Standardwert: Date.now()

Initialisiert Fake-Timer mit der angegebenen Unix-Epoche.

fakeTimers.toFake

Typ: ('setTimeout' | 'clearTimeout' | 'setImmediate' | 'clearImmediate' | 'setInterval' | 'clearInterval' | 'Date' | 'nextTick' | 'hrtime' | 'requestAnimationFrame' | 'cancelAnimationFrame' | 'requestIdleCallback' | 'cancelIdleCallback' | 'performance' | 'queueMicrotask')[]
Standardwert: ['setTimeout', 'clearTimeout', 'setImmediate', 'clearImmediate', 'setInterval', 'clearInterval', 'Date']

Ein Array mit den Namen globaler Methoden und APIs, die simuliert werden sollen.

Um nur setTimeout() und nextTick() zu simulieren, geben Sie diese Eigenschaft als ['setTimeout', 'nextTick'] an.

Das Simulieren von nextTick wird nicht unterstützt, wenn Vitest innerhalb von node:child_process mit --pool=forks ausgeführt wird. NodeJS verwendet process.nextTick intern in node:child_process und blockiert, wenn es simuliert wird. Das Simulieren von nextTick wird unterstützt, wenn Vitest mit --pool=threads ausgeführt wird.

fakeTimers.loopLimit

Typ: number
Standardwert: 10_000

Die maximale Anzahl an Timern, die beim Aufruf von vi.runAllTimers() ausgeführt werden.

fakeTimers.shouldAdvanceTime

Typ: boolean
Standardwert: false

Weist @sinonjs/fake-timers an, die simulierte Zeit automatisch basierend auf der realen Systemzeitverschiebung zu erhöhen (z. B. wird die simulierte Zeit um 20 ms für jede 20-ms-Änderung der realen Systemzeit erhöht).

fakeTimers.advanceTimeDelta

Typ: number
Standardwert: 20

Relevant nur bei Verwendung mit shouldAdvanceTime: true. Erhöht die simulierte Zeit um advanceTimeDelta ms für jede advanceTimeDelta ms-Änderung der realen Systemzeit.

fakeTimers.shouldClearNativeTimers

Typ: boolean
Standardwert: false

Weist Fake-Timer an, "native" (d. h. nicht simulierte) Timer zu löschen, indem sie an ihre jeweiligen Handler delegieren. Diese werden standardmäßig nicht gelöscht, was zu potenziell unerwartetem Verhalten führen kann, wenn Timer bereits vor dem Starten der Fake-Timer-Sitzung existierten.

workspace* 1.1.0+

Typ: string
CLI: --workspace=./file.js
Standardwert: vitest.{workspace,projects}.{js,ts,json} in der Nähe der Konfigurationsdatei oder des Stammverzeichnisses

Pfad zu einer Workspace-Konfigurationsdatei, relativ zu root.

isolate 1.1.0+

Typ: boolean
Standardwert: true
CLI: --no-isolate, --isolate=false

Führt Tests in einer isolierten Umgebung aus. Diese Option hat keine Auswirkung auf die vmThreads- und vmForks-Pools.

Das Deaktivieren dieser Option kann die Leistung verbessern, wenn Ihr Code keine Seiteneffekte verursacht (was typischerweise für Projekte mit node-Umgebung zutrifft).

TIP

Sie können die Isolation für bestimmte Pools deaktivieren, indem Sie die Eigenschaft poolOptions verwenden.

includeTaskLocation 1.4.0+

Typ: boolean
Standardwert: false

Soll die Eigenschaft location eingeschlossen werden, wenn die Vitest-API Aufgaben an Reporter sendet? Bei einer großen Anzahl von Tests kann dies zu einer geringfügigen Leistungseinbuße führen.

Die Eigenschaft location enthält die Werte column und line, die der Position von test oder describe in der Originaldatei entsprechen.

TIP

Diese Option hat keine Auswirkungen, wenn Sie keinen benutzerdefinierten Code verwenden, der darauf angewiesen ist.

snapshotEnvironment 1.6.0+

Typ: string

Pfad zu einer benutzerdefinierten Snapshot-Umgebungsimplementierung. Dies ist nützlich, wenn Sie Ihre Tests in einer Umgebung ausführen, die keine Node.js-APIs unterstützt. Diese Option hat keine Auswirkung auf einen Browser-Runner.

Dieses Objekt sollte die Form von SnapshotEnvironment haben und wird verwendet, um Snapshot-Dateien aufzulösen und zu lesen/zu schreiben:

export interface SnapshotEnvironment {
  getVersion: () => string;
  getHeader: () => string;
  resolvePath: (filepath: string) => Promise<string>;
  resolveRawPath: (testPath: string, rawPath: string) => Promise<string>;
  saveSnapshotFile: (filepath: string, snapshot: string) => Promise<void>;
  readSnapshotFile: (filepath: string) => Promise<string | null>;
  removeSnapshotFile: (filepath: string) => Promise<void>;
}

Sie können die Standard-VitestSnapshotEnvironment vom vitest/snapshot-Einstiegspunkt erweitern, wenn Sie nur einen Teil der API überschreiben müssen.

WARNING

Dies ist eine Low-Level-Option und sollte nur in fortgeschrittenen Fällen verwendet werden, in denen Sie keinen Zugriff auf die Standard-Node.js-APIs haben.

Wenn Sie lediglich die Snapshot-Funktion konfigurieren müssen, verwenden Sie die Optionen snapshotFormat oder resolveSnapshotPath.

Vitest konfigurieren ​

include ​

exclude ​

includeSource ​

server 0.34.0+ ​

server.sourcemap ​

server.debug ​

server.debug.dumpModules ​

server.debug.loadDumppedModules ​

server.deps ​

server.deps.external ​

server.deps.inline ​

server.deps.fallbackCJS ​

server.deps.cacheDir ​

deps ​

deps.optimizer 0.34.0+ ​

deps.optimizer.{mode}.enabled ​

deps.web 0.34.2+ ​

deps.web.transformAssets ​

deps.web.transformCss ​

deps.web.transformGlobPattern ​

deps.interopDefault ​

deps.moduleDirectories ​

runner ​

benchmark ​

benchmark.include ​

benchmark.exclude ​

benchmark.includeSource ​

benchmark.reporters ​

benchmark.outputFile ​

benchmark.outputJson 1.6.0+ ​

benchmark.compare 1.6.0+ ​

alias ​

globals ​

environment ​

environmentOptions ​

environmentMatchGlobs ​

poolMatchGlobs 0.29.4+ ​

update* ​

watch* ​

root ​

reporters* ​

outputFile* ​

pool* 1.0.0+ ​

threads* ​

forks* ​

vmThreads* ​

vmForks* ​

poolOptions* 1.0.0+ ​

poolOptions.threads ​

poolOptions.threads.maxThreads* ​

poolOptions.threads.minThreads* ​

poolOptions.threads.singleThread ​

poolOptions.threads.useAtomics* ​

poolOptions.threads.isolate ​

poolOptions.threads.execArgv* ​

poolOptions.forks ​

poolOptions.forks.maxForks* ​

poolOptions.forks.minForks* ​

poolOptions.forks.isolate ​

poolOptions.forks.singleFork ​

poolOptions.forks.execArgv* ​

poolOptions.vmThreads ​

poolOptions.vmThreads.maxThreads* ​

poolOptions.vmThreads.minThreads* ​

poolOptions.vmThreads.memoryLimit* ​

poolOptions.vmThreads.useAtomics* ​

poolOptions.vmThreads.execArgv* ​

poolOptions.vmForks ​

poolOptions.vmForks.maxForks* ​

poolOptions.vmForks.minForks* ​

poolOptions.vmForks.memoryLimit* ​

poolOptions.vmForks.execArgv* ​

fileParallelism 1.1.0+ ​

maxWorkers 1.1.0+ ​

minWorkers 1.1.0+ ​

testTimeout ​

hookTimeout ​

teardownTimeout* ​

silent* ​

Vitest konfigurieren

include

exclude

includeSource

server 0.34.0+

server.sourcemap

server.debug

server.debug.dumpModules

server.debug.loadDumppedModules

server.deps

server.deps.external

server.deps.inline

server.deps.fallbackCJS

server.deps.cacheDir

deps

deps.optimizer 0.34.0+

deps.optimizer.{mode}.enabled

deps.web 0.34.2+

deps.web.transformAssets

deps.web.transformCss

deps.web.transformGlobPattern

deps.interopDefault

deps.moduleDirectories

runner

benchmark

benchmark.include

benchmark.exclude

benchmark.includeSource

benchmark.reporters

benchmark.outputFile

benchmark.outputJson 1.6.0+

benchmark.compare 1.6.0+

alias

globals

environment

environmentOptions

environmentMatchGlobs

poolMatchGlobs 0.29.4+

update*

watch*

root

reporters*

outputFile*

pool* 1.0.0+

threads*

forks*

vmThreads*

vmForks*

poolOptions* 1.0.0+

poolOptions.threads

poolOptions.threads.maxThreads*

poolOptions.threads.minThreads*

poolOptions.threads.singleThread

poolOptions.threads.useAtomics*

poolOptions.threads.isolate

poolOptions.threads.execArgv*

poolOptions.forks

poolOptions.forks.maxForks*

poolOptions.forks.minForks*

poolOptions.forks.isolate

poolOptions.forks.singleFork

poolOptions.forks.execArgv*

poolOptions.vmThreads

poolOptions.vmThreads.maxThreads*

poolOptions.vmThreads.minThreads*

poolOptions.vmThreads.memoryLimit*

poolOptions.vmThreads.useAtomics*

poolOptions.vmThreads.execArgv*

poolOptions.vmForks

poolOptions.vmForks.maxForks*

poolOptions.vmForks.minForks*

poolOptions.vmForks.memoryLimit*

poolOptions.vmForks.execArgv*

fileParallelism 1.1.0+

maxWorkers 1.1.0+

minWorkers 1.1.0+

testTimeout

hookTimeout

teardownTimeout*

silent*