Konfiguration von Vitest

Konfiguration

vitest liest Ihre Stammkonfigurationsdatei vite.config.ts, falls vorhanden, um die Plugins und Konfigurationen Ihrer Vite-Anwendung zu übernehmen. Wenn Sie eine separate Testkonfiguration benötigen oder Ihre Hauptanwendung nicht auf Vite basiert, haben Sie folgende Möglichkeiten:

• Erstellen Sie eine vitest.config.ts-Datei. Diese Datei hat eine höhere Priorität und überschreibt die Konfiguration aus vite.config.ts.
• Übergeben Sie die Option --config an die Befehlszeile, z. B. vitest --config ./pfad/zu/vitest.config.ts.
• Verwenden Sie process.env.VITEST oder die Eigenschaft mode in defineConfig (wird auf test/benchmark gesetzt, falls nicht überschrieben), um bedingt eine andere Konfiguration in vite.config.ts anzuwenden.

Fügen Sie die test-Eigenschaft in Ihrer Vite-Konfiguration hinzu, um vitest zu konfigurieren. Sie müssen außerdem eine Referenz zu Vitest-Typen hinzufügen, indem Sie einen Triple-Slash-Befehl am Anfang Ihrer Konfigurationsdatei verwenden, wenn Sie defineConfig aus vite selbst importieren.

Wenn Sie defineConfig aus vite verwenden, beachten Sie Folgendes:

/// <reference types="vitest" />
import { defineConfig } from 'vite';

export default defineConfig({
  test: {
    // ...
  },
});

Wenn Sie defineConfig aus vitest/config verwenden, beachten Sie Folgendes:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // ...
  },
});

Sie können die Standardoptionen von Vitest abrufen, um sie bei Bedarf zu erweitern:

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

export default defineConfig({
  test: {
    exclude: [...configDefaults.exclude, 'packages/template/*'],
  },
});

Wenn Sie eine separate vitest.config.js verwenden, können Sie die Vite-Optionen aus einer anderen Konfigurationsdatei erweitern:

import { defineConfig, mergeConfig } from 'vitest/config';
import viteConfig from './vite.config';

export default mergeConfig(
  viteConfig,
  defineConfig({
    test: {
      exclude: ['packages/template/*'],
    },
  })
);

WARNING

Der mergeConfig-Helfer ist in Vitest ab v0.30.0 verfügbar. Sie können ihn direkt von vite importieren, wenn Sie eine ältere Version verwenden.

Wenn Ihre Vite-Konfiguration als Funktion definiert ist, können Sie die Konfiguration wie folgt definieren:

import { defineConfig, mergeConfig } from 'vitest/config';
import viteConfig from './vite.config';

export default defineConfig(configEnv =>
  mergeConfig(
    viteConfig(configEnv),
    defineConfig({
      test: {
        exclude: ['packages/template/*'],
      },
    })
  )
);

Optionen

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.

TIP

Alle Konfigurationsoptionen, die in einem Workspace-Projekt nicht unterstützt werden, sind mit einem *-Zeichen versehen.

include

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

Dateien, die durch ein Glob-Muster für den Testlauf berücksichtigt werden.

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.*']

Dateien, die durch ein Glob-Muster vom Testlauf ausgeschlossen werden.

includeSource

• Typ: string[]
• Standardwert: []

Include-Globs für Testdateien im Quellcode.

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

server

• Typ: { sourcemap?, deps?, ... }
• Version: Seit Vitest 0.34.0

Vite-Node Server Optionen.

server.sourcemap

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

Sourcemaps direkt in die Module einfügen.

server.debug

• Typ: { dumpModules?, loadDumppedModules? }

Vite-Node Debugger Optionen.

server.debug.dumpModules

• Typ: boolean | string

Das transformierte Modul in das Dateisystem ausgeben. Wenn eine Zeichenkette übergeben wird, wird es in den angegebenen Pfad ausgegeben.

server.debug.loadDumppedModules

• Typ: boolean

Das ausgegebene Modul aus dem Dateisystem lesen, falls vorhanden. Nützlich für das Debuggen durch Ändern des Dump-Ergebnisses im Dateisystem.

server.deps

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

Steuerung der Abhängigkeitsauflösung.

server.deps.external

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

Externalisieren bedeutet, dass Vite das Paket direkt an Node.js übergibt. Externalisierte Abhängigkeiten werden von Vites Transformatoren und Resolvern nicht verarbeitet, sodass sie kein HMR beim Neuladen unterstützen. Standardmäßig werden alle Pakete innerhalb von node_modules externalisiert.

Diese Optionen unterstützen Paketnamen, wie sie in node_modules geschrieben sind oder in deps.moduleDirectories angegeben werden. 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. Grundsätzlich prüft Vitest immer den Dateipfad, nicht den tatsächlichen Paketnamen.

Wenn ein regulärer Ausdruck verwendet wird, wendet Vitest ihn auf den Dateipfad an, nicht auf den Paketnamen.

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 sein. Alle Abhängigkeiten, die in ssr.noExternal angegeben sind, werden standardmäßig inline sein.

server.deps.fallbackCJS

• Typ: boolean
• Standardwert: false

Wenn eine Abhängigkeit ein gültiges ESM-Paket ist, wird versucht, die CJS-Version anhand des Pfads zu ermitteln. Dies kann hilfreich sein, wenn eine Abhängigkeit die falsche ESM-Datei hat.

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

server.deps.cacheDir

• Typ: string
• Standardwert: 'node_modules/.vite'

Verzeichnis zum Speichern von Cache-Dateien.

deps

• Typ: { optimizer?, registerNodeLoader?, ... }

Steuerung der Abhängigkeitsauflösung.

deps.optimizer

• Typ: { ssr?, web? }
• Version: Seit Vitest 0.34.0
• Siehe auch: Dep Optimization Options (Optionen zur Optimierung von Abhängigkeiten)

Aktivieren Sie die Abhängigkeitsoptimierung. Dies kann die Leistung Ihrer Tests verbessern, wenn Sie viele davon haben. Vor Vitest 0.34.0 wurde diese Option als deps.experimentalOptimizer bezeichnet.

Wenn Vitest eine in include aufgeführte externe Bibliothek findet, wird diese mit esbuild in eine einzige Datei gebündelt und als vollständiges Modul importiert. Dies ist aus mehreren Gründen vorteilhaft:

• Das Importieren von Paketen mit vielen Importen ist aufwändig. Indem wir sie in einer Datei bündeln, können wir viel Zeit sparen.
• Das Importieren von UI-Bibliotheken ist aufwändig, 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 ähnlich wie im Browser ausgeführt.

Beachten Sie, dass nur Pakete in der Option deps.optimizer?.[mode].include gebündelt werden (einige Plugins füllen dies automatisch aus, wie z. B. Svelte). Sie können mehr über die verfügbaren Optionen in den Vite-Dokumenten 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 Ihre optimizeDeps beim Ausführen von Tests erweitert. 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 die erneute Bündelung mit der Option deps.optimizer?.[mode].force.

deps.optimizer.{mode}.enabled

• Typ: boolean
• Standardwert: true, wenn >= Vite 4.3.2 verwendet wird, andernfalls false

Aktivieren Sie die Abhängigkeitsoptimierung.

WARNING

Diese Option wird nur von Vite 4.3.2 oder neuer unterstützt.

deps.web

• Typ: { transformAssets?, ... }
• Version: Seit Vite 0.34.2

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 innerhalb dieser 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.) wie Vite im Browser verarbeiten und auflösen?

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

WARNING

Im Moment funktioniert diese Option nur mit dem experimentalVmThreads-Pool.

deps.web.transformCss

• Typ: boolean
• Standardwert: true

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

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

WARNING

Im Moment funktioniert diese Option nur mit dem experimentalVmThreads-Pool.

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 dem experimentalVmThreads-Pool.

deps.registerNodeLoader*

• Typ: boolean
• Standardwert: false

Verwenden Sie den experimentellen Node-Loader, um Importe innerhalb von externalisierten Dateien mit dem Vite-Auflösungsalgorithmus aufzulösen.

Wenn diese Option deaktiviert ist, beeinflussen Ihre alias und <plugin>.resolveId keine Importe innerhalb von externalisierten Paketen (standardmäßig node_modules).

deps.interopDefault

• Typ: boolean
• Standardwert: true

Behandeln Sie den Standardwert des CJS-Moduls 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, sehen Sie diesen Fehler:

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 sehen Sie diesen Fehler höchstwahrscheinlich beim Ausführen von Tests, wenn diese Funktion deaktiviert ist:

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

Standardmäßig geht Vitest davon aus, 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 gelten. 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 zu finden, 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 Setzen dieser Option überschreibt den Standardwert. Wenn Sie node_modules weiterhin 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

Pfadangabe für einen angepassten 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)']

Include-Globs für Benchmark-Testdateien.

benchmark.exclude

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

Exclude-Globs für Benchmark-Testdateien.

benchmark.includeSource

• Typ: string[]
• Standardwert: []

Include-Globs für Benchmark-Testdateien im Quellcode. 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'

Benutzerdefinierter Ausgabereporter. Kann einen oder mehrere integrierte Berichtsnamen, Reporter-Instanzen und/oder Pfade zu benutzerdefinierten Reportern enthalten.

benchmark.outputFile

• Typ: string | Record<string, string>

Schreiben Sie Benchmark-Ergebnisse in eine Datei, wenn auch die Option --reporter=json angegeben ist. Indem Sie ein Objekt anstelle einer Zeichenfolge bereitstellen, 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.

alias

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

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

globals

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

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

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

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

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

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

Wenn Sie bereits unplugin-auto-import in Ihrem Projekt verwenden, können Sie es auch direkt für den automatischen Import dieser APIs verwenden.

// vite.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
• Standard: 'node'
• CLI: --environment=<env>

Die Umgebung, die für die Ausführung der Tests verwendet wird. Die Standardumgebung in Vitest ist Node.js. Für Webanwendungen können Sie eine browserähnliche Umgebung mit jsdom oder happy-dom verwenden. Für Edge Functions 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-Stil:

/**
 * @vitest-environment jsdom
 */

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

Kommentarstil:

// @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 --threads=false ausgeführt wird, werden die Tests in der folgenden Reihenfolge ausgeführt: node, jsdom, happy-dom, edge-runtime, custom environments (benutzerdefinierte Umgebungen). Dies ermöglicht die Gruppierung und sequenzielle Ausführung von Tests mit derselben Umgebung.

Ab Version 0.23.0 können Sie auch benutzerdefinierte Umgebungen 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() {
    // Benutzerdefinierte Einrichtung
    return {
      teardown() {
        // Wird aufgerufen, nachdem alle Tests in dieser Umgebung abgeschlossen sind
      },
    };
  },
};

Vitest stellt außerdem builtinEnvironments über den Eintrag vitest/environments bereit, falls eine Erweiterung erforderlich ist. Weitere Informationen zum Erweitern von Umgebungen finden Sie in unserem Leitfaden.

environmentOptions

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

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

environmentMatchGlobs

• Typ: [string, EnvironmentName][]
• Standard: []

Weist automatisch eine Umgebung basierend auf Glob-Mustern 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

• Typ: [string, 'threads' | 'child_process' | 'experimentalVmThreads'][]
• Standard: []
• Version: Seit Vitest 0.29.4

Weist automatisch einen Pool zu, in dem Tests basierend auf Glob-Mustern 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 `--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
• Standard: false
• CLI: -u, --update, --update=false

Aktualisiert Snapshot-Dateien. Dies aktualisiert alle geänderten Snapshots und löscht veraltete.

watch*

• Typ: boolean
• Standard: true
• CLI: -w, --watch, --watch=false

Aktiviert den Watch-Modus.

root

• Typ: string
• CLI: -r <path>, --root=<path>

Projektstammverzeichnis.

reporters*

• Typ: Reporter | Reporter[]
• Standard: 'default'
• CLI: --reporter=<name>, --reporter=<name1> --reporter=<name2>

Benutzerdefinierte Reporter für die Ausgabe von Testergebnissen. Reporter können entweder eine Reporter-Instanz oder ein String sein, um integrierte Reporter auszuwählen:

• 'default' - Blendet Testsuiten aus, wenn diese erfolgreich sind.
• 'basic' - Gibt einen Reporter ähnlich dem Standardreporter in CI aus.
• 'verbose' - Behält die vollständige Aufgabenstruktur bei.
• 'dot' - Stellt jede Aufgabe als einzelnen Punkt dar.
• 'junit' - JUnit XML-Reporter (Sie können den Tag-Namen testsuites mit der Umgebungsvariable VITEST_JUNIT_SUITE_NAME und die Tag-Eigenschaft classname mit VITEST_JUNIT_CLASSNAME konfigurieren).
• 'json' - Gibt eine einfache Zusammenfassung im JSON-Format aus.
• 'html' - Gibt einen HTML-Bericht auf Basis von @vitest/ui aus.
• 'hanging-process' - Listet hängende Prozesse auf, wenn Vitest den Prozess nicht sicher beenden kann. Dies kann eine aufwändige Operation sein, aktivieren Sie sie nur, wenn Vitest den Prozess nicht konsistent beenden kann.
• Pfad eines benutzerdefinierten Reporters (z. B. './path/to/reporter.ts', '@scope/reporter').

outputFile*

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

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

experimentalVmThreads

• Typ: boolean
• CLI: --experimentalVmThreads, --experimental-vm-threads
• Version: Seit Vitest 0.34.0

Führt Tests im VM-Kontext (innerhalb einer Sandbox-Umgebung) in einem Worker-Pool aus.

Dadurch werden Tests schneller ausgeführt, aber das VM-Modul ist instabil, wenn ESM-Code ausgeführt wird. Ihre Tests können Speicherlecks verursachen. Um dies zu verhindern, sollte der Wert experimentalVmWorkerMemoryLimit manuell angepasst werden.

WARNING

Die Codeausführung in einer Sandbox bietet zwar Vorteile (schnellere Tests), bringt aber auch Nachteile mit sich.

• 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 von diesen nativen Modulen ausgelöste Fehler auf einen anderen Error-Konstruktor als den, der im Code verwendet wird:

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

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

Bitte beachten Sie diese Punkte bei der Verwendung dieser Option. Das Vitest-Team kann diese Probleme nicht beheben.

experimentalVmWorkerMemoryLimit

• Typ: string | number
• CLI: --experimentalVmWorkerMemoryLimit, --experimental-vm-worker-memory-limit
• Standard: 1 / CPU-Kerne
• Version: Seit Vitest 0.34.0

Gibt den Speichergrenzwert für Worker an, bevor diese wiederverwendet werden. Dieser Wert hängt stark von Ihrer Umgebung ab, daher ist es besser, ihn manuell anzugeben, anstatt sich auf den Standardwert zu verlassen.

Diese Option betrifft nur Worker, die Tests im VM-Kontext ausführen.

TIP

Die Implementierung orientiert sich an 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. So setzt 0,5 den Speichergrenzwert des Workers auf die Hälfte des gesamten Systemspeichers.

• \> 1 - Wird als fester Bytewert angenommen. Basierend auf der vorherigen Regel könnte man 1.1 verwenden, wenn ein Wert von 1 Byte gewünscht ist.

• Mit Einheiten

  • 50% - Wie oben, ein Prozentsatz des gesamten Systemspeichers.

  • 100KB, 65MB usw. - Mit Einheiten, um einen festen Speichergrenzwert anzugeben.

    • K / KB - Kilobyte (x1000)
    • KiB - Kibibyte (x1024)
    • M / MB - Megabyte
    • MiB - Mebibyte
    • G / GB - Gigabyte
    • GiB - Gibibyte

WARNING

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

threads

• Typ: boolean
• Standard: true
• CLI: --threads, --threads=false

Aktiviert Multi-Threading mit tinypool (einem leichtgewichtigen Fork von Piscina). Vor Vitest 0.29.0 führte Vitest Tests immer noch innerhalb eines Worker-Threads aus, selbst wenn diese Option deaktiviert war. Ab Version 0.29.0 verwendet Vitest bei deaktivierter Option child_process, um einen Prozess zu starten und die Tests darin auszuführen. Dies ermöglicht die Verwendung von process.chdir und anderen APIs, die in Workern nicht verfügbar waren. Wenn Sie zum vorherigen Verhalten zurückkehren möchten, verwenden Sie stattdessen die Option --single-thread.

Das Deaktivieren dieser Option führt dazu, dass alle Tests innerhalb mehrerer Kindprozesse ausgeführt werden.

singleThread

• Typ: boolean
• Standard: false
• Version: Seit Vitest 0.29.0

Führt alle Tests mit derselben Umgebung innerhalb eines einzelnen Worker-Threads aus. Dies deaktiviert die integrierte Modulisolation (Ihr Quellcode oder inline Code wird für jeden Test weiterhin neu bewertet), kann aber die Testleistung verbessern. Vor Vitest 0.29.0 entsprach dies der Verwendung von --no-threads.

WARNING

Auch wenn diese Option Tests dazu zwingt, nacheinander ausgeführt zu werden, unterscheidet sich diese Option von Jests --runInBand. Vitest verwendet Worker nicht nur, um Tests parallel auszuführen, sondern auch, um Isolation bereitzustellen. Durch das Deaktivieren dieser Option werden Ihre Tests sequenziell, aber im selben globalen Kontext ausgeführt, sodass Sie die Isolation selbst bereitstellen müssen.

Dies kann alle möglichen Probleme verursachen, 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 die Testgeschwindigkeit erhöhen (bis zu 3x schneller), besonders bei Tests, die nicht auf globalen Zustand angewiesen sind oder diesen leicht umgehen können.

maxThreads*

• Typ: number
• Standard: verfügbare CPUs

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

minThreads*

• Typ: number
• Standard: verfügbare CPUs

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

useAtomics*

• Typ: boolean
• Standard: false
• Version: Seit Vitest 0.28.3

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.

testTimeout

• Typ: number
• Standard: 5000
• CLI: --test-timeout=5000

Standard-Timeout für Tests in Millisekunden.

hookTimeout

• Typ: number
• Standard: 10000

Standard-Timeout für Hooks in Millisekunden.

teardownTimeout*

• Typ: number
• Standard: 10000

Standard-Timeout für das Warten auf das Schließen, wenn Vitest herunterfährt, in Millisekunden.

silent*

• Typ: boolean
• Standard: false
• CLI: --silent, --silent=false

Deaktiviert die Konsolenausgabe von Tests.

setupFiles

• Typ: string | string[]

Pfad zu den Setup-Dateien. Sie werden vor jeder Testdatei ausgeführt.

INFO

Änderungen an Setup-Dateien führen zur Neuausführung aller Tests.

Mithilfe von process.env.VITEST_POOL_ID (Integer als String) kann zwischen Threads unterschieden werden (ist immer '1', wenn mit threads: false ausgeführt).

TIP

Bitte beachten Sie, dass, wenn Sie --threads=false ausführen, diese Setup-Datei mehrmals im selben globalen Gültigkeitsbereich ausgeführt wird. Dies bedeutet, dass vor jedem Test auf dasselbe globale Objekt zugegriffen wird. Es sollte also darauf geachtet werden, nicht mehr als nötig zu tun.

Sie können sich beispielsweise auf eine globale Variable verlassen:

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 den globalen Setup-Dateien, relativ zum Projektstammverzeichnis.

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

INFO

Mehrere globale Setup-Dateien werden unterstützt. Setup und Teardown werden sequenziell ausgeführt, wobei Teardown in umgekehrter Reihenfolge erfolgt.

WARNING

Bitte beachten Sie, dass das globale Setup in einem anderen globalen Scope ausgeführt wird, sodass Ihre Tests keinen Zugriff auf hier definierte Variablen haben.

watchExclude*

• Typ: string[]
• Standard: ['**/node_modules/**', '**/dist/**']

Glob-Muster für Dateipfade, die ignoriert werden sollen, um die erneute Ausführung im Watch-Modus auszulösen.

forceRerunTriggers*

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

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

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 der Inhalt von `dist/index.js` geändert wurde.
  await execa('node', ['dist/index.js']);
});

TIP

Es sollte sichergestellt werden, dass die Dateien nicht durch watchExclude ausgeschlossen werden.

isolate

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

Isolierte Umgebung für jede Testdatei. Funktioniert nur, wenn Sie --threads nicht deaktivieren.

Diese Option hat keine Auswirkung auf experimentalVmThreads.

coverage*

Sie können v8, istanbul oder eine benutzerdefinierte Coverage-Lösung für die Coverage-Erfassung verwenden.

Sie können Coverage-Optionen über die CLI mit Punktnotation angeben:

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

WARNING

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

coverage.provider

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

Verwenden Sie provider, um das Tool für die Coverage-Erfassung auszuwählen.

coverage.enabled

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

Aktiviert die Coverage-Erfassung. Kann mit der 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 als Glob-Muster in die Coverage einbezogen werden sollen.

coverage.extension

• Typ: string | string[]
• Standardwert: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.cts', '.tsx', '.jsx', '.vue', '.svelte']
• 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}.?(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 als Glob-Muster von der Coverage ausgeschlossen werden sollen.

coverage.all

• Typ: boolean
• Standardwert: false
• 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

Bereinigt den Coverage-Bericht bei jeder erneuten Ausführung im Watch-Modus.

coverage.reportsDirectory

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

Verzeichnis, in das der Coverage-Bericht geschrieben werden soll.

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>

Die zu verwendenden 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 auf drei verschiedene Arten konfiguriert werden:

• Einzelner Reporter: { reporter: 'html' }
• Mehrere Reporter ohne Optionen: { reporter: ['html', 'json'] }
• Einzelner oder mehrere Reporter mit Reporter-Optionen:

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

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

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

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

Erfasst Coverage-Daten auch für 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% Statement-, Branch- und Funktionsabdeckung aus.

coverage.perFile

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

Prüft die Schwellenwerte für jede Datei einzeln. Die tatsächlichen Schwellenwerte finden Sie unter lines, functions, branches und statements.

coverage.thresholdAutoUpdate

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

Aktualisiert die Schwellenwerte lines, functions, branches und statements in der Konfigurationsdatei, falls die aktuelle Coverage die konfigurierten Schwellenwerte übersteigt. Diese Option hilft, die Schwellenwerte aktuell zu halten, wenn die Coverage verbessert wird.

coverage.lines

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

Schwellwert für Zeilen. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.functions

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

Schwellwert für Funktionen. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.branches

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

Schwellwert für Verzweigungen. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.statements

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

Schwellwert für Anweisungen. Weitere Informationen finden Sie in der Istanbul-Dokumentation.

coverage.100

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

Abkürzung für --coverage.lines 100 --coverage.functions 100 --coverage.branches 100 --coverage.statements 100.

coverage.ignoreClassMethods

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

Array von Klassennamen der Methoden, die 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'

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

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 Anleitung - Benutzerdefinierter Coverage-Provider.

testNamePattern*

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

Führt Tests aus, deren vollständige Namen mit dem Muster übereinstimmen. Wenn Sie dieser Eigenschaft OnlyRunThis hinzufügen, werden Tests, die das Wort OnlyRunThis nicht im Testnamen enthalten, übersprungen.

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: false
• CLI: --open, --open=false

Öffnet die Vitest-UI (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

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

Führt Vitest-Tests in einem Browser aus. Standardmäßig verwenden wir WebdriverIO zum Ausführen von Tests, dies kann aber mit der Option browser.provider konfiguriert werden.

NOTE

Lesen Sie mehr über das Testen in einem echten Browser auf der Anleitungsseite.

WARNING

Dies ist eine experimentelle Funktion. Breaking Changes können auch in Minor- oder Patch-Versionen auftreten. Bitte fixieren Sie die Vitest-Version, wenn Sie sie verwenden.

browser.enabled

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

Führt standardmäßig alle Tests in einem Browser aus. 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 Zeichenfolge, die an den Provider übergeben wird

browser.headless

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

Führt den Browser im Headless-Modus aus. Wenn Sie Vitest in CI ausführen, wird dies standardmäßig aktiviert.

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 den Code im Browser bereitstellt. Hat keine Auswirkungen auf die Option test.api.

browser.provider

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

Der Pfad zu einem Provider, der für die Ausführung von Browser-Tests verwendet wird. Vitest bietet zwei Provider: webdriverio (Standard) und playwright. Benutzerdefinierte Provider sollten mit dem default-Export exportiert werden und folgende Struktur haben:

export interface BrowserProvider {
  name: string;
  getSupportedBrowsers(): readonly string[];
  initialize(ctx: Vitest, options: { browser: string }): 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.slowHijackESM

• Typ: boolean
• Standard: true
• Version: Seit Vitest 0.31.0

Wenn Tests in Node.js ausgeführt werden, kann Vitest seine eigene Modulauflösung verwenden, um Module einfach mit der vi.mock-Syntax zu mocken. Die Nachbildung der ES-Modulauflösung im Browser ist jedoch aufwendiger. Daher müssen die Quelldateien transformiert werden, bevor der Browser sie verarbeiten kann.

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

Wenn Sie weder vi.spyOn zum Ausspionieren von ES-Modulen noch vi.mock verwenden, können Sie diese Option deaktivieren, um die Leistung leicht zu verbessern.

clearMocks

• Typ: boolean
• Standard: false

Vor jedem Testlauf wird .mockClear() für alle Spione aufgerufen. Dadurch wird die Mock-Historie gelöscht, die Standardimplementierung jedoch nicht zurückgesetzt.

mockReset

• Typ: boolean
• Standard: false

Vor jedem Testlauf wird .mockReset() für alle Spione aufgerufen. Dadurch wird die Mock-Historie gelöscht und die Implementierung auf eine Funktion ohne Implementierung zurückgesetzt, die undefined zurückgibt.

restoreMocks

• Typ: boolean
• Standard: false

Vor jedem Testlauf wird .mockRestore() für alle Spione aufgerufen. Dadurch wird die Mock-Historie gelöscht und die Implementierung auf die ursprüngliche zurückgesetzt.

unstubEnvs

• Typ: boolean
• Standard: false
• Version: Seit Vitest 0.26.0

Ruft vor jedem Testlauf vi.unstubAllEnvs auf.

unstubGlobals

• Typ: boolean
• Standard: false
• Version: Seit Vitest 0.26.0

Ruft vor jedem Testlauf vi.unstubAllGlobals auf.

testTransformMode

• Typ: { web?, ssr? }
• Version: Seit Vitest 0.34.0

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

testTransformMode.ssr

• Typ: string[]
• Standard: []

Verwendet die SSR-Transformationspipeline für alle Module innerhalb der angegebenen Tests. Vite-Plugins erhalten das Flag ssr: true, wenn sie diese Dateien verarbeiten.

testTransformMode.web

• Typ: string[]
• Standard: []

Führt zuerst eine normale Transformationspipeline (mit Zielbrowser) und anschließend eine SSR-Neuschreibung durch, um den Code in Node auszuführen. Vite-Plugins erhalten das Flag ssr: false, wenn sie diese Dateien verarbeiten.

snapshotFormat*

• Typ: PrettyFormatOptions

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

resolveSnapshotPath*

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

Überschreibt den Standard-Speicherpfad für Snapshots. Um Snapshots beispielsweise neben Testdateien zu speichern:

import { defineConfig } from 'vitest/config';

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

allowOnly

• Typ: boolean
• Standard: false
• CLI: --allowOnly, --allowOnly=false

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

dangerouslyIgnoreUnhandledErrors*

• Typ: boolean
• Standard: false
• CLI: --dangerouslyIgnoreUnhandledErrors --dangerouslyIgnoreUnhandledErrors=false

Ignoriert alle auftretenden, unbehandelten Fehler.

passWithNoTests*

• Typ: boolean
• Standard: false
• CLI: --passWithNoTests, --passWithNoTests=false

Vitest gibt keinen Fehler aus, wenn keine Tests gefunden werden.

logHeapUsage

• Typ: boolean
• Standard: false
• CLI: --logHeapUsage, --logHeapUsage=false

Zeigt die Heap-Auslastung nach jedem Test an. Dies ist nützlich, um Speicherlecks zu debuggen.

css

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

Konfiguriert, ob CSS-Dateien verarbeitet werden sollen. Wenn CSS-Dateien ausgeschlossen werden, werden sie durch leere Zeichenketten ersetzt, um die nachfolgende Verarbeitung zu umgehen. CSS-Module geben ein Proxy-Objekt zurück, um die Laufzeit nicht zu beeinflussen.

css.include

• Typ: RegExp | RegExp[]
• Standard: []

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

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

css.modules

• Typ: { classNameStrategy? }
• Standard: {}

css.modules.classNameStrategy

• Typ: 'stable' | 'scoped' | 'non-scoped'
• Standard: 'stable'

Wenn Sie CSS-Dateien verarbeiten, können Sie konfigurieren, ob die Klassennamen innerhalb von CSS-Modulen "scoped" sein sollen. Sie können eine der folgenden Optionen auswählen:

• stable: Klassennamen werden als _${name}_${hashedFilename} generiert. Das bedeutet, dass der generierte Name gleich bleibt, wenn sich der CSS-Inhalt ändert, sich aber ändert, 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, sofern diese vorhanden und die CSS-Verarbeitung aktiviert ist. Standardmäßig wird der Dateiname als _${name}_${hash} generiert, wobei der Hash den Dateinamen und den Inhalt der Datei enthält.
• non-scoped: Klassennamen werden nicht gehasht.

WARNING

Standardmäßig exportiert Vitest einen Proxy, der die Verarbeitung von CSS-Modulen umgeht. Wenn Sie sich auf CSS-Eigenschaften in Ihren Klassen verlassen, müssen Sie die CSS-Verarbeitung mit der Option include aktivieren.

maxConcurrency

• Typ: number
• Standard: 5

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

Tests, die dieses Limit überschreiten, werden in eine Warteschlange eingereiht und ausgeführt, sobald ein Slot frei wird.

cache*

• Typ: false | { dir? }

Optionen zum Konfigurieren der Vitest-Cache-Richtlinie. Aktuell speichert Vitest Testergebnisse im Cache, um längere und fehlgeschlagene Tests zuerst auszuführen.

cache.dir

• Typ: string
• Standard: node_modules/.vitest

Pfad zum Cache-Verzeichnis.

sequence

• Typ: { sequencer?, shuffle?, seed?, hooks?, setupFiles? }

Optionen zur Festlegung der Reihenfolge, in der Tests ausgeführt werden.

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

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

sequence.sequencer*

• Typ: TestSequencerConstructor
• Standard: 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 und shard neu definieren müssen, aber beide sollten vorhanden sein.

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

sequence.shuffle

• Typ: boolean
• Standard: false
• CLI: --sequence.shuffle, --sequence.shuffle=false

Wenn Sie die Tests in zufälliger Reihenfolge ausführen möchten, können Sie diese Option oder das CLI-Argument --sequence.shuffle aktivieren.

Vitest verwendet normalerweise den Cache, um Tests zu sortieren, sodass langlaufende Tests früher gestartet werden, was die Testausführung beschleunigt. Wenn Ihre Tests in zufälliger Reihenfolge ausgeführt werden, geht diese Leistungsverbesserung verloren. Es kann jedoch nützlich sein, Tests zu identifizieren, die unbeabsichtigt von einem vorherigen Testlauf abhängen.

sequence.concurrent

• Typ: boolean
• Standard: false
• CLI: --sequence.concurrent, --sequence.concurrent=false
• Version: Seit Vitest 0.32.2

Wenn Sie die Tests parallel ausführen möchten, können Sie diese Option oder das CLI-Argument --sequence.concurrent aktivieren.

sequence.seed*

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

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

sequence.hooks

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

Ändert die Reihenfolge, in der Hooks ausgeführt werden.

• stack ordnet "after"-Hooks in umgekehrter Reihenfolge an. "before"-Hooks werden in der Reihenfolge ausgeführt, in der sie definiert wurden.
• list ordnet alle Hooks in der Reihenfolge an, in der sie definiert sind.
• parallel führt Hooks in einer einzigen Gruppe parallel aus. Hooks in übergeordneten Suiten werden weiterhin vor den Hooks der aktuellen Suite ausgeführt.

sequence.setupFiles

• Typ: 'list' | 'parallel'
• Standard: 'parallel'
• CLI: --sequence.setupFiles=<value>
• Version: Seit Vitest 0.29.3

Ändert die Reihenfolge, in der Setup-Dateien ausgeführt werden.

• list führt Setup-Dateien in der Reihenfolge aus, in der sie definiert sind.
• parallel führt Setup-Dateien parallel aus.

typecheck

Optionen zum Konfigurieren der Testumgebung für die Typprüfung.

typecheck.checker

• Typ: 'tsc' | 'vue-tsc' | string
• Standard: tsc

Welche Tools für die Typprüfung verwendet werden sollen. Vitest erzeugt einen Prozess mit bestimmten Parametern, um die Analyse zu vereinfachen, abhängig vom Typ. Der Checker sollte das gleiche Ausgabeformat wie tsc verwenden.

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

• tsc erfordert das Paket typescript
• vue-tsc erfordert das Paket vue-tsc

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

typecheck.include

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

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

typecheck.exclude

• Typ: string[]
• Standard: ['**/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
• Standard: false

Überprüfen Sie JS-Dateien, die den Kommentar @ts-check haben. Wenn Sie dies in tsconfig aktiviert haben, wird dies nicht überschrieben.

typecheck.ignoreSourceErrors

• Typ: boolean
• Standard: false

Geben Sie keinen Fehler aus, wenn Vitest Fehler außerhalb der Testdateien findet. Dadurch werden Ihnen keinerlei Fehler außerhalb der Tests angezeigt.

Standardmäßig gibt die Testsuite einen Fehler aus, wenn Vitest einen Quellfehler findet.

typecheck.tsconfig

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

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

slowTestThreshold*

• Typ: number
• Standard: 300

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

chaiConfig

• Typ: { includeStack?, showDiff?, truncateThreshold? }
• Standard: { includeStack: false, showDiff: true, truncateThreshold: 40 }
• Version: Seit Vitest 0.30.0

Entspricht der Chai-Konfiguration.

chaiConfig.includeStack

• Typ: boolean
• Standard: 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
• Standard: true

Beeinflusst, ob das Flag showDiff in den ausgelösten AssertionErrors enthalten sein soll. false ist immer false. true ist true, wenn die Assertion angefordert hat, dass ein Diff angezeigt wird.

chaiConfig.truncateThreshold

• Typ: number
• Standard: 40

Legt die Längenschwelle für tatsächliche und erwartete Werte in Assertionsfehlermeldungen fest. Wenn diese Schwelle überschritten wird, beispielsweise bei großen Datenstrukturen, wird der Wert durch etwas wie [ Array(3) ] oder { Object (prop1, prop2) } ersetzt. Setzen Sie den Wert auf 0, wenn Sie das Abschneiden vollständig deaktivieren möchten.

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

bail

• Typ: number
• Standard: 0
• CLI: --bail=<value>
• Version: Seit Vitest 0.31.0

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

Dies ist möglicherweise nicht für CI-Builds erwünscht, bei denen nur vollständig erfolgreiche Builds von Interesse sind und die Testausführung bei Auftreten von Testfehlern so früh wie möglich beendet werden soll. Mit der Option bail kann die Ausführung von CI-Builds beschleunigt werden, indem verhindert wird, dass weitere Tests ausgeführt werden, nachdem Fehler aufgetreten sind.

retry

• Typ: number
• Standard: 0
• CLI: --retry=<value>
• Version: Seit Vitest 0.32.3

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

onConsoleLog

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

Benutzerdefinierte Funktion zur Behandlung von console.log-Ausgaben in Tests. Wenn Sie false zurückgeben, verhindert Vitest die Ausgabe des Logs in der Konsole.

Kann nützlich sein, um Log-Ausgaben von Drittbibliotheken herauszufiltern.

import { defineConfig } from 'vitest/config';

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

diff

• Typ: string
• CLI: --diff=<value>
• Version: Seit Vitest 0.34.5

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

vitest.diff.ts

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

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

vitest.config.js

import { defineConfig } from 'vitest/config';

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