Kommandozeilenschnittstelle

Befehle

vitest

Startet Vitest im aktuellen Verzeichnis. Im Entwicklungsmodus wechselt Vitest automatisch in den Beobachtungsmodus, in der CI-Umgebung in den Ausführungsmodus.

Sie können ein zusätzliches Argument als Filter für die auszuführenden Testdateien übergeben. Zum Beispiel:

vitest foobar

Führt nur die Testdateien aus, deren Pfad foobar enthält. Dieser Filter prüft lediglich auf Inklusion und unterstützt keine regulären Ausdrücke oder Glob-Muster (es sei denn, Ihr Terminal verarbeitet diese, bevor Vitest den Filter empfängt).

vitest run

Führt Tests einmalig aus, ohne den Beobachtungsmodus zu aktivieren.

vitest watch

Führt alle Testsuiten aus und überwacht Änderungen. Bei Änderungen werden die Tests erneut ausgeführt. Entspricht dem Aufruf von vitest ohne Argument. In CI-Umgebungen wird automatisch vitest run ausgeführt.

vitest dev

Alias für vitest watch.

vitest related

Führt nur Tests aus, die eine Liste von Quelldateien abdecken. Funktioniert mit statischen Importen (z. B. import('./index.js') oder import index from './index.js'), jedoch nicht mit dynamischen Importen (z. B. import(filepath)). Alle Dateien sollten relativ zum Projektstammverzeichnis sein.

Nützlich in Kombination mit lint-staged oder in Ihrer CI-Umgebung.

vitest related /src/index.ts /src/hello-world.js

TIP

Beachten Sie, dass Vitest standardmäßig mit aktiviertem Beobachtungsmodus ausgeführt wird. Wenn Sie Tools wie lint-staged verwenden, sollten Sie zusätzlich die Option --run übergeben, damit der Befehl ordnungsgemäß abgeschlossen wird.

// .lintstagedrc.js
export default {
  '*.{js,ts}': 'vitest related --run',
};

vitest bench

Führt nur Benchmark-Tests aus, die Leistungsergebnisse vergleichen.

Optionen

Optionen
-r, --root <Pfad>	Wurzelpfad
-c, --config <Pfad>	Pfad zur Konfigurationsdatei
-u, --update	Snapshot aktualisieren
-w, --watch	Watch-Modus aktivieren
-t, --testNamePattern <Muster>	Führt Tests mit vollständigen Namen aus, die dem angegebenen Regexp-Muster entsprechen
--dir <Pfad>	Basisverzeichnis, in dem nach Testdateien gesucht wird
--ui	UI aktivieren
--open	UI automatisch öffnen (Standard: !process.env.CI)
--api.port [port]	Server-Port festlegen. Hinweis: Wenn der Port bereits verwendet wird, versucht Vite automatisch den nächsten verfügbaren Port, sodass dies nicht der tatsächliche Port sein muss, auf dem der Server letztendlich lauscht. Wenn true, wird er auf 51204 gesetzt.
--api.host [host]	Geben Sie an, auf welchen IP-Adressen der Server lauschen soll. Setzen Sie dies auf 0.0.0.0 oder true, um auf allen Adressen zu lauschen, einschließlich LAN- und öffentlichen Adressen.
--api.strictPort	Bei true beenden, wenn der Port bereits verwendet wird, anstatt automatisch den nächsten verfügbaren Port zu versuchen
--silent	Stummschalten der Konsolenausgabe von Tests
--hideSkippedTests	Ausblenden von Protokollen für übersprungene Tests
--reporter <Name>	Reporter angeben
--outputFile <Dateiname/-n>	Testergebnisse in eine Datei schreiben, wenn auch ein unterstützter Reporter angegeben ist. Verwenden Sie die Punktnotation von CAC für individuelle Ausgaben mehrerer Reporter (Beispiel: --outputFile.tap=./tap.txt)
--coverage.all	Ob alle, auch die ungetesteten Dateien, in den Bericht aufgenommen werden sollen
--coverage.provider <Name>	Wählen Sie das Tool für die Coverage-Collection aus. Verfügbare Werte sind: "v8", "istanbul" und "custom"
--coverage.enabled	Aktiviert die Coverage-Collection. Kann mit der CLI-Option "--coverage" überschrieben werden (Standard: false)
--coverage.include <Muster>	Dateien, die in der Coverage enthalten sind, als Glob-Muster. Kann mehrfach angegeben werden, wenn mehrere Muster verwendet werden (Standard: **)
--coverage.exclude <Muster>	Dateien, die in der Coverage ausgeschlossen werden sollen. Kann mehrfach angegeben werden, wenn mehrere Erweiterungen verwendet werden (Standard: Besuchen Sie coverage.exclude)
--coverage.extension <Erweiterung>	Erweiterung, die in der Coverage enthalten sein soll. Kann mehrfach angegeben werden, wenn mehrere Erweiterungen verwendet werden (Standard: [".js", ".cjs", ".mjs", ".ts", ".mts", ".cts", ".tsx", ".jsx", ".vue", ".svelte"])
--coverage.clean	Coverage-Ergebnisse vor dem Ausführen von Tests bereinigen (Standard: true)
--coverage.cleanOnRerun	Coverage-Bericht beim erneuten Ausführen im Watch-Modus bereinigen (Standard: true)
--coverage.reportsDirectory <Pfad>	Verzeichnis, in das der Coverage-Bericht geschrieben werden soll (Standard: ./coverage)
--coverage.reporter <Name>	Zu verwendende Coverage-Reporter. Besuchen Sie coverage.reporter für weitere Informationen (Standard: ["text", "html", "clover", "json"])
--coverage.reportOnFailure	Coverage-Bericht auch dann generieren, wenn Tests fehlschlagen (Standard: false)
--coverage.allowExternal	Coverage von Dateien außerhalb des Projekt-Root erfassen (Standard: false)
--coverage.skipFull	Dateien mit 100% Statement-, Branch- und Funktionsabdeckung nicht anzeigen (Standard: false)
--coverage.thresholds.100	Abkürzung, um alle Coverage-Schwellenwerte auf 100 zu setzen (Standard: false)
--coverage.thresholds.perFile	Schwellenwerte pro Datei prüfen. Siehe --coverage.thresholds.lines, --coverage.thresholds.functions, --coverage.thresholds.branches und --coverage.thresholds.statements für die tatsächlichen Schwellenwerte (Standard: false)
--coverage.thresholds.autoUpdate	Schwellenwerte "lines", "functions", "branches" und "statements" in der Konfigurationsdatei aktualisieren, wenn die aktuelle Coverage über den konfigurierten Schwellenwerten liegt (Standard: false)
--coverage.thresholds.lines <Zahl>	Schwellenwert für Zeilen. Besuchen Sie istanbuljs für weitere Informationen. Diese Option ist für benutzerdefinierte Provider nicht verfügbar
--coverage.thresholds.functions <Zahl>	Schwellenwert für Funktionen. Besuchen Sie istanbuljs für weitere Informationen. Diese Option ist für benutzerdefinierte Provider nicht verfügbar
--coverage.thresholds.branches <Zahl>	Schwellenwert für Branches. Besuchen Sie istanbuljs für weitere Informationen. Diese Option ist für benutzerdefinierte Provider nicht verfügbar
--coverage.thresholds.statements <Zahl>	Schwellenwert für Statements. Besuchen Sie istanbuljs für weitere Informationen. Diese Option ist für benutzerdefinierte Provider nicht verfügbar
--coverage.ignoreClassMethods <Name>	Array von Klassemethodennamen, die für die Coverage ignoriert werden sollen. Besuchen Sie istanbuljs für weitere Informationen. Diese Option ist nur für die Istanbul-Provider verfügbar (Standard: [])
--coverage.processingConcurrency <Anzahl>	Beschränkung der Parallelität bei der Verarbeitung der Coverage-Ergebnisse. (Standard: Minimum zwischen 20 und der Anzahl der CPUs)
--coverage.customProviderModule <Pfad>	Gibt den Modulnamen oder -pfad für das benutzerdefinierte Coverage-Provider-Modul an. Besuchen Sie Custom Coverage Provider für weitere Informationen. Diese Option ist nur für benutzerdefinierte Provider verfügbar
--coverage.watermarks.statements <Wasserzeichen>	Hohe und niedrige Wasserzeichen für Statements im Format <hoch>,<niedrig>
--coverage.watermarks.lines <Wasserzeichen>	Hohe und niedrige Wasserzeichen für Zeilen im Format <hoch>,<niedrig>
--coverage.watermarks.branches <Wasserzeichen>	Hohe und niedrige Wasserzeichen für Branches im Format <hoch>,<niedrig>
--coverage.watermarks.functions <Wasserzeichen>	Hohe und niedrige Wasserzeichen für Funktionen im Format <hoch>,<niedrig>
--mode <Name>	Vite-Modus überschreiben (Standard: test oder benchmark)
--workspace <Pfad>	Pfad zu einer Workspace-Konfigurationsdatei
--isolate	Jede Testdatei in Isolation ausführen. Um die Isolation zu deaktivieren, verwenden Sie --no-isolate (Standard: true)
--globals	APIs global injizieren
--dom	Browser-API mit happy-dom mocken
--browser.enabled	Tests im Browser ausführen. Entspricht --browser.enabled (Standard: false)
--browser.name <name>	Führt alle Tests in einem bestimmten Browser aus. Einige Browser sind nur für bestimmte Provider verfügbar (siehe --browser.provider). Besuchen Sie browser.name für weitere Informationen
--browser.headless	Führt den Browser im Headless-Modus aus (d. h. ohne Öffnen der GUI (Graphical User Interface)). Wenn Sie Vitest in CI ausführen, wird dies standardmäßig aktiviert (Standard: process.env.CI)
--browser.api.port [port]	Server-Port festlegen. Hinweis: Wenn der Port bereits verwendet wird, versucht Vite automatisch den nächsten verfügbaren Port, sodass dies nicht der tatsächliche Port sein muss, auf dem der Server letztendlich lauscht. Wenn true, wird er auf 63315 gesetzt.
--browser.api.host [host]	Geben Sie an, auf welchen IP-Adressen der Server lauschen soll. Setzen Sie dies auf 0.0.0.0 oder true, um auf allen Adressen zu lauschen, einschließlich LAN- und öffentlichen Adressen.
--browser.api.strictPort	Auf true setzen, um zu beenden, wenn der Port bereits verwendet wird, anstatt automatisch den nächsten verfügbaren Port zu versuchen
--browser.provider <name>	Provider für die Ausführung von Browser-Tests. Einige Browser sind nur für bestimmte Provider verfügbar. Kann "webdriverio", "playwright" oder der Pfad zu einem benutzerdefinierten Provider sein. Besuchen Sie browser.provider für weitere Informationen (Standard: "webdriverio")
--browser.providerOptions <options>	Optionen, die an einen Browser-Provider weitergegeben werden. Besuchen Sie browser.providerOptions für weitere Informationen
--browser.slowHijackESM	Vitest seine eigene Modulauflösung im Browser verwenden lassen, um APIs wie vi.mock und vi.spyOn zu aktivieren. Besuchen Sie browser.slowHijackESM für weitere Informationen (Standard: false)
--browser.isolate	Führen Sie jede Browser-Testdatei isoliert aus. Um die Isolation zu deaktivieren, verwenden Sie --browser.isolate=false (Standard: true)
--browser.fileParallelism	Sollen alle Testdateien parallel ausgeführt werden? Verwenden Sie --browser.file-parallelism=false, um dies zu deaktivieren (Standard: dasselbe wie --file-parallelism)
--pool <Pool>	Pool angeben, wenn nicht im Browser ausgeführt (Standard: threads)
--poolOptions.threads.isolate	Tests im Thread-Pool isolieren (Standard: true)
--poolOptions.threads.singleThread	Tests in einem einzigen Thread ausführen (Standard: false)
--poolOptions.threads.maxThreads <Worker>	Maximale Anzahl an Threads, in denen Tests ausgeführt werden
--poolOptions.threads.minThreads <Worker>	Minimale Anzahl an Threads, in denen Tests ausgeführt werden
--poolOptions.threads.useAtomics	Atomics verwenden, um Threads zu synchronisieren. Dies kann die Leistung in einigen Fällen verbessern, aber in älteren Node-Versionen zu Segfaults führen (Standard: false)
--poolOptions.vmThreads.isolate	Tests im Thread-Pool isolieren (Standard: true)
--poolOptions.vmThreads.singleThread	Tests in einem einzigen Thread ausführen (Standard: false)
--poolOptions.vmThreads.maxThreads <Worker>	Maximale Anzahl an Threads, in denen Tests ausgeführt werden
--poolOptions.vmThreads.minThreads <Worker>	Minimale Anzahl an Threads, in denen Tests ausgeführt werden
--poolOptions.vmThreads.useAtomics	Atomics verwenden, um Threads zu synchronisieren. Dies kann die Leistung in einigen Fällen verbessern, aber in älteren Node-Versionen zu Segfaults führen (Standard: false)
--poolOptions.vmThreads.memoryLimit <Limit>	Speicherlimit für den VM-Thread-Pool. Wenn Sie Speicherlecks feststellen, versuchen Sie, diesen Wert anzupassen.
--poolOptions.forks.isolate	Tests im Forks-Pool isolieren (Standard: true)
--poolOptions.forks.singleFork	Tests in einem einzelnen child_process ausführen (Standard: false)
--poolOptions.forks.maxForks <Worker>	Maximale Anzahl an Prozessen, in denen Tests ausgeführt werden
--poolOptions.forks.minForks <Worker>	Minimale Anzahl an Prozessen, in denen Tests ausgeführt werden
--poolOptions.vmForks.isolate	Tests im Forks-Pool isolieren (Standard: true)
--poolOptions.vmForks.singleFork	Tests in einem einzelnen child_process ausführen (Standard: false)
--poolOptions.vmForks.maxForks <Worker>	Maximale Anzahl an Prozessen, in denen Tests ausgeführt werden
--poolOptions.vmForks.minForks <Worker>	Minimale Anzahl an Prozessen, in denen Tests ausgeführt werden
--poolOptions.vmForks.memoryLimit <Limit>	Speicherlimit für den VM-Forks-Pool. Wenn Sie Speicherlecks feststellen, versuchen Sie, diesen Wert anzupassen.
--fileParallelism	Sullen alle Testdateien parallel ausgeführt werden. Verwenden Sie --no-file-parallelism, um dies zu deaktivieren (Standard: true)
--maxWorkers <Worker>	Maximale Anzahl an Workern, in denen Tests ausgeführt werden
--minWorkers <Worker>	Minimale Anzahl an Workern, in denen Tests ausgeführt werden
--environment <Name>	Runner-Umgebung angeben, wenn nicht im Browser ausgeführt (Standard: node)
--passWithNoTests	Bestehen, wenn keine Tests gefunden werden
--logHeapUsage	Die Größe des Heaps für jeden Test anzeigen, wenn in Node ausgeführt wird
--allowOnly	Tests und Suiten zulassen, die als "only" markiert sind (Standard: !process.env.CI)
--dangerouslyIgnoreUnhandledErrors	Alle unbehandelten Fehler ignorieren, die auftreten
--shard <Shards>	Test Suite Shard zur Ausführung im Format <Index>/<Anzahl>
--changed [Seit]	Führen Sie Tests aus, die von den geänderten Dateien betroffen sind (Standard: false)
--sequence.shuffle.files	Dateien in zufälliger Reihenfolge ausführen. Lang andauernde Tests werden nicht früher gestartet, wenn Sie diese Option aktivieren. (Standard: false)
--sequence.shuffle.tests	Tests in zufälliger Reihenfolge ausführen (Standard: false)
--sequence.concurrent	Tests parallel ausführen (Standard: false)
--sequence.seed <Seed>	Legen Sie den Randomisierungs-Seed fest. Diese Option hat keine Auswirkung, wenn --sequence.shuffle falsch ist. Besuchen Sie die Seite "Random Seed" für weitere Informationen
--sequence.hooks <Order>	Ändert die Reihenfolge, in der Hooks ausgeführt werden. Akzeptierte Werte sind: "stack", "list" und "parallel". Besuchen Sie sequence.hooks für weitere Informationen (Standard: "parallel")
--sequence.setupFiles <Order>	Ändert die Reihenfolge, in der Setup-Dateien ausgeführt werden. Akzeptierte Werte sind: "list" und "parallel". Wenn auf "list" gesetzt, werden Setup-Dateien in der Reihenfolge ausgeführt, in der sie definiert sind. Wenn auf "parallel" gesetzt, werden Setup-Dateien parallel ausgeführt (Standard: "parallel")
--inspect [[Host:]Port]	Node.js Inspector aktivieren (Standard: 127.0.0.1:9229)
--inspectBrk [[Host:]Port]	Node.js Inspector aktivieren und vor dem Teststart anhalten
--testTimeout <Timeout>	Standard-Timeout eines Tests in Millisekunden (Standard: 5000)
--hookTimeout <Timeout>	Standard-Hook-Timeout in Millisekunden (Standard: 10000)
--bail <Anzahl>	Testausführung stoppen, wenn eine bestimmte Anzahl von Tests fehlgeschlagen ist (Standard: 0)
--retry <Anzahl>	Den Test eine bestimmte Anzahl von Malen wiederholen, wenn er fehlschlägt (Standard: 0)
--diff <Pfad>	Pfad zu einer Diff-Konfiguration, die zum Generieren der Diff-Schnittstelle verwendet wird
--exclude <Glob>	Zusätzliche Dateiglobs, die von Tests ausgeschlossen werden sollen
--expandSnapshotDiff	Volle Differenz anzeigen, wenn Snapshot fehlschlägt
--disableConsoleIntercept	Automatische Abfangung der Konsolenausgabe deaktivieren (Standard: false)
--typecheck.enabled	Aktiviert die Typüberprüfung zusammen mit Tests (Standard: false)
--typecheck.only	Führen Sie nur Typüberprüfungstests aus. Dadurch wird die Typüberprüfung automatisch aktiviert (Standard: false)
--typecheck.checker <Name>	Geben Sie den zu verwendenden Typchecker an. Verfügbare Werte sind: "tcs" und "vue-tsc" sowie ein Pfad zu einer ausführbaren Datei (Standard: "tsc")
--typecheck.allowJs	JavaScript-Dateien dürfen typgeprüft werden. Standardmäßig wird der Wert aus tsconfig.json übernommen
--typecheck.ignoreSourceErrors	Ignoriert Typfehler aus Quelldateien
--typecheck.tsconfig <Pfad>	Pfad zu einer benutzerdefinierten tsconfig-Datei
--project <Name>	Der Name des Projekts, das ausgeführt werden soll, wenn Sie die Vitest-Workspace-Funktion verwenden. Dies kann für mehrere Projekte wiederholt werden: --project=1 --project=2. Sie können Projekte auch mit Platzhaltern filtern, wie z. B. --project=packages*
--slowTestThreshold <Schwellenwert>	Schwellenwert in Millisekunden, ab dem ein Test als langsam gilt (Standard: 300)
--teardownTimeout <Timeout>	Standard-Timeout einer Teardown-Funktion in Millisekunden (Standard: 10000)
--maxConcurrency <Anzahl>	Maximale Anzahl gleichzeitiger Tests in einer Suite (Standard: 5)
--run	Watch-Modus deaktivieren
--segfaultRetry <Zeiten>	Versuchen Sie die Testsuite erneut, wenn sie aufgrund eines Segfaults abstürzt (Standard: true)
--no-color	Entfernt Farben aus der Konsolenausgabe
--clearScreen	Löschen Sie den Terminalbildschirm, wenn Tests im Watch-Modus erneut ausgeführt werden (Standard: true)
--standalone	Starten Sie Vitest, ohne Tests auszuführen. Dateifilter werden ignoriert, Tests werden nur bei Änderungen ausgeführt (Standard: false)

TIP

Vitest unterstützt sowohl Camel Case als auch Kebab Case für CLI-Argumente. Zum Beispiel funktionieren --passWithNoTests und --pass-with-no-tests beide (--no-color und --inspect-brk sind die Ausnahmen).

Vitest unterstützt auch verschiedene Möglichkeiten, den Wert anzugeben: --reporter dot und --reporter=dot sind beide gültig.

Wenn eine Option ein Array von Werten unterstützt, müssen Sie die Option mehrmals übergeben:

vitest --reporter=dot --reporter=default

Boolesche Optionen können mit dem Präfix no- negiert werden. Die Angabe des Werts als false funktioniert ebenfalls:

vitest --no-api
vitest --api=false

changed

• Typ: boolean | string

• Standard: false

  Führt Tests nur für geänderte Dateien aus. Wenn kein Wert angegeben wird, werden Tests für nicht commitete Änderungen ausgeführt (einschließlich staged und unstaged Änderungen).

  Um Tests für Änderungen am letzten Commit auszuführen, können Sie --changed HEAD~1 verwenden. Sie können auch einen Commit-Hash (z. B. --changed 09a9920) oder einen Branch-Namen (z. B. --changed origin/develop) übergeben.

  Bei Verwendung mit Code Coverage enthält der Bericht nur die Dateien, die sich auf die Änderungen beziehen.

  In Kombination mit der Konfigurationsoption forceRerunTriggers wird die gesamte Testsuite ausgeführt, wenn sich mindestens eine der in der Liste forceRerunTriggers aufgeführten Dateien ändert. Standardmäßig führen Änderungen an der Vitest-Konfigurationsdatei und an package.json immer die gesamte Suite erneut aus.

shard

• Typ: string

• Standard: deaktiviert

  Testsuite-Shard, der im Format <index>/<count> ausgeführt werden soll, wobei

  • count eine positive ganze Zahl ist, die die Anzahl der Shards angibt
  • index eine positive ganze Zahl ist, die den Index des Shards angibt

  Dieser Befehl teilt alle Tests in count gleich große Shards auf und führt nur die Tests aus, die sich im index-Shard befinden. Um Ihre Testsuite beispielsweise in drei Shards aufzuteilen, verwenden Sie Folgendes:

  vitest run --shard=1/3
  vitest run --shard=2/3
  vitest run --shard=3/3

WARNING

Diese Option kann nicht verwendet werden, wenn --watch aktiviert ist (standardmäßig in der Entwicklungsumgebung aktiviert).