Interface de ligne de commande

Commandes

vitest

Démarre Vitest dans le répertoire courant. Bascule automatiquement en mode surveillance en environnement de développement et en mode exécution en environnement CI.

Vous pouvez passer un argument supplémentaire pour filtrer les fichiers de test à exécuter. Par exemple :

vitest foobar

N'exécutera que les fichiers de test dont le chemin contient foobar. Ce filtre vérifie simplement l'inclusion et ne prend pas en charge les expressions régulières ou les motifs glob (sauf si votre terminal les interprète avant que Vitest ne reçoive le filtre).

vitest run

Effectue une seule exécution sans mode surveillance.

vitest watch

Exécute toutes les suites de tests, puis surveille les modifications et réexécute les tests en cas de changement. Équivalent à appeler vitest sans argument. Revient à vitest run en CI.

vitest dev

Alias de vitest watch.

vitest related

Exécute uniquement les tests qui couvrent une liste de fichiers sources. Fonctionne avec les importations statiques (par exemple, import('./index.js') ou import index from './index.js'), mais pas avec les importations dynamiques (par exemple, import(filepath)). Tous les fichiers doivent être relatifs au dossier racine.

Il est utile de l'exécuter avec lint-staged ou avec votre configuration CI.

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

TIP

N'oubliez pas que Vitest s'exécute avec le mode surveillance activé par défaut. Si vous utilisez des outils comme lint-staged, vous devez également passer l'option --run, afin que la commande puisse se terminer normalement.

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

vitest bench

Exécute uniquement les tests de benchmark, qui permettent de comparer les performances.

Options

Options
-r, --root <path>	Chemin racine
-c, --config <path>	Chemin vers le fichier de configuration
-u, --update	Mettre à jour le snapshot
-w, --watch	Activer le mode surveillance
-t, --testNamePattern <pattern>	Exécuter les tests avec des noms complets correspondant au modèle regexp spécifié
--dir <path>	Répertoire de base pour la recherche des fichiers de test
--ui	Activer l'interface utilisateur
--open	Ouvrir l'interface utilisateur automatiquement (par défaut : !process.env.CI)
--api.port [port]	Spécifier le port du serveur. Notez que si le port est déjà utilisé, Vite essaiera automatiquement le prochain port disponible, donc ce n'est peut-être pas le port réel sur lequel le serveur finira par écouter. Si vrai, sera défini sur 51204
--api.host [host]	Spécifier les adresses IP sur lesquelles le serveur doit écouter. Définissez ceci sur 0.0.0.0 ou true pour écouter sur toutes les adresses, y compris les adresses LAN et publiques
--api.strictPort	Définir sur true pour quitter si le port est déjà utilisé, au lieu d'essayer automatiquement le prochain port disponible
--silent	Sortie console silencieuse des tests
--hideSkippedTests	Masquer les logs pour les tests ignorés
--reporter <name>	Spécifier les reporters
--outputFile <filename/-s>	Écrire les résultats des tests dans un fichier lorsque le reporter supporter est également spécifié, utiliser la notation pointée de cac pour les sorties individuelles de plusieurs reporters (exemple: --outputFile.tap=./tap.txt)
--coverage.all	Indique s'il faut inclure tous les fichiers, y compris ceux qui n'ont pas été testés, dans le rapport
--coverage.provider <name>	Sélectionner l'outil de collecte de couverture, les valeurs disponibles sont: "v8", "istanbul" et "custom"
--coverage.enabled	Active la collecte de couverture. Peut être remplacé en utilisant l'option CLI --coverage (par défaut: false)
--coverage.include <pattern>	Fichiers inclus dans la couverture en tant que modèles glob. Peut être spécifié plusieurs fois lors de l'utilisation de plusieurs modèles (par défaut: **)
--coverage.exclude <pattern>	Fichiers à exclure de la couverture. Peut être spécifié plusieurs fois lors de l'utilisation de plusieurs extensions (par défaut: Voir coverage.exclude)
--coverage.extension <extension>	Extension à inclure dans la couverture. Peut être spécifié plusieurs fois lors de l'utilisation de plusieurs extensions (par défaut: [".js", ".cjs", ".mjs", ".ts", ".mts", ".cts", ".tsx", ".jsx", ".vue", ".svelte"])
--coverage.clean	Nettoyer les résultats de la couverture avant d'exécuter les tests (par défaut: true)
--coverage.cleanOnRerun	Nettoyer le rapport de couverture lors de la réexécution en mode surveillance (par défaut: true)
--coverage.reportsDirectory <path>	Répertoire dans lequel écrire le rapport de couverture (par défaut: ./coverage)
--coverage.reporter <name>	Reporters de couverture à utiliser. Visitez coverage.reporter pour plus d'informations (par défaut: ["text", "html", "clover", "json"])
--coverage.reportOnFailure	Générer un rapport de couverture même lorsque les tests échouent (par défaut: false)
--coverage.allowExternal	Collecter la couverture des fichiers en dehors de la racine du projet (par défaut: false)
--coverage.skipFull	Ne pas afficher les fichiers avec une couverture à 100% des instructions, des branches et des fonctions (par défaut: false)
--coverage.thresholds.100	Raccourci pour définir tous les seuils de couverture à 100 (par défaut: false)
--coverage.thresholds.perFile	Vérifier les seuils par fichier. Voir --coverage.thresholds.lines, --coverage.thresholds.functions, --coverage.thresholds.branches et --coverage.thresholds.statements pour les seuils réels (par défaut: false)
--coverage.thresholds.autoUpdate	Mettre à jour les valeurs seuils: "lines", "functions", "branches" et "statements" dans le fichier de configuration lorsque la couverture actuelle est supérieure aux seuils configurés (par défaut: false)
--coverage.thresholds.lines <number>	Seuil pour les lignes. Visitez istanbuljs pour plus d'informations. Cette option n'est pas disponible pour les fournisseurs personnalisés
--coverage.thresholds.functions <number>	Seuil pour les fonctions. Visitez istanbuljs pour plus d'informations. Cette option n'est pas disponible pour les fournisseurs personnalisés
--coverage.thresholds.branches <number>	Seuil pour les branches. Visitez istanbuljs pour plus d'informations. Cette option n'est pas disponible pour les fournisseurs personnalisés
--coverage.thresholds.statements <number>	Seuil pour les instructions. Visitez istanbuljs pour plus d'informations. Cette option n'est pas disponible pour les fournisseurs personnalisés
--coverage.ignoreClassMethods <name>	Tableau des noms de méthodes de classe à ignorer pour la couverture. Visitez istanbuljs pour plus d'informations. Cette option est uniquement disponible pour les fournisseurs istanbul (par défaut: [])
--coverage.processingConcurrency <number>	Limite de concurrence utilisée lors du traitement des résultats de la couverture. (par défaut, le min entre 20 et le nombre de CPU)
--coverage.customProviderModule <path>	Spécifie le nom du module ou le chemin du module de fournisseur de couverture personnalisé. Visitez Custom Coverage Provider pour plus d'informations. Cette option est uniquement disponible pour les fournisseurs personnalisés
--coverage.watermarks.statements <watermarks>	Filigranes élevés et bas pour les instructions au format <high>,<low>
--coverage.watermarks.lines <watermarks>	Filigranes élevés et bas pour les lignes au format <high>,<low>
--coverage.watermarks.branches <watermarks>	Filigranes élevés et bas pour les branches au format <high>,<low>
--coverage.watermarks.functions <watermarks>	Filigranes élevés et bas pour les fonctions au format <high>,<low>
--mode <name>	Remplacer le mode Vite (par défaut: test ou benchmark)
--workspace <path>	Chemin vers un fichier de configuration d'espace de travail
--isolate	Exécuter chaque fichier de test de manière isolée. Pour désactiver l'isolation, utilisez --no-isolate (par défaut: true)
--globals	Injecter les API globalement
--dom	Simuler l'API du navigateur avec happy-dom
--browser.enabled	Exécuter les tests dans le navigateur. Équivalent à --browser.enabled (par défaut: false)
--browser.name <name>	Exécuter tous les tests dans un navigateur spécifique. Certains navigateurs ne sont disponibles que pour des fournisseurs spécifiques (voir --browser.provider). Visitez browser.name pour plus d'informations
--browser.headless	Exécuter le navigateur en mode headless (c'est-à-dire sans ouvrir l'interface utilisateur graphique (GUI)). Si vous exécutez Vitest en CI, il sera activé par défaut (par défaut: process.env.CI)
--browser.api.port [port]	Spécifier le port du serveur. Notez que si le port est déjà utilisé, Vite essaiera automatiquement le prochain port disponible, donc ce n'est peut-être pas le port réel sur lequel le serveur finira par écouter. Si vrai, sera défini sur 63315
--browser.api.host [host]	Spécifier les adresses IP sur lesquelles le serveur doit écouter. Définissez ceci sur 0.0.0.0 ou true pour écouter sur toutes les adresses, y compris les adresses LAN et publiques
--browser.api.strictPort	Définir sur true pour quitter si le port est déjà utilisé, au lieu d'essayer automatiquement le prochain port disponible
--browser.provider <name>	Fournisseur utilisé pour exécuter les tests du navigateur. Certains navigateurs ne sont disponibles que pour des fournisseurs spécifiques. Peut être "webdriverio", "playwright" ou le chemin vers un fournisseur personnalisé. Visitez browser.provider pour plus d'informations (par défaut: "webdriverio")
--browser.providerOptions <options>	Options qui sont transmises à un fournisseur de navigateur. Visitez browser.providerOptions pour plus d'informations
--browser.slowHijackESM	Laisser Vitest utiliser sa propre résolution de module sur le navigateur pour activer les API telles que vi.mock et vi.spyOn. Visitez browser.slowHijackESM pour plus d'informations (par défaut: false)
--browser.isolate	Exécuter chaque fichier de test de navigateur de manière isolée. Pour désactiver l'isolation, utilisez --browser.isolate=false (par défaut: true)
--browser.fileParallelism	Tous les fichiers de test doivent-ils s'exécuter en parallèle. Utilisez --browser.file-parallelism=false pour désactiver (par défaut: identique à --file-parallelism)
--pool <pool>	Spécifier le pool, si l'exécution n'est pas dans le navigateur (par défaut: threads)
--poolOptions.threads.isolate	Isoler les tests dans le pool de threads (par défaut: true)
--poolOptions.threads.singleThread	Exécuter les tests dans un seul thread (par défaut: false)
--poolOptions.threads.maxThreads <workers>	Nombre maximal de threads pour exécuter les tests
--poolOptions.threads.minThreads <workers>	Nombre minimal de threads pour exécuter les tests
--poolOptions.threads.useAtomics	Utiliser Atomics pour synchroniser les threads. Cela peut améliorer les performances dans certains cas, mais peut provoquer un segfault dans les anciennes versions de Node (par défaut: false)
--poolOptions.vmThreads.isolate	Isoler les tests dans le pool de threads (par défaut: true)
--poolOptions.vmThreads.singleThread	Exécuter les tests dans un seul thread (par défaut: false)
--poolOptions.vmThreads.maxThreads <workers>	Nombre maximal de threads pour exécuter les tests
--poolOptions.vmThreads.minThreads <workers>	Nombre minimal de threads pour exécuter les tests
--poolOptions.vmThreads.useAtomics	Utiliser Atomics pour synchroniser les threads. Cela peut améliorer les performances dans certains cas, mais peut provoquer un segfault dans les anciennes versions de Node (par défaut: false)
--poolOptions.vmThreads.memoryLimit <limit>	Limite de mémoire pour le pool de threads VM. Si vous constatez des fuites de mémoire, essayez de modifier cette valeur.
--poolOptions.forks.isolate	Isoler les tests dans le pool de forks (par défaut: true)
--poolOptions.forks.singleFork	Exécuter les tests dans un seul child_process (par défaut: false)
--poolOptions.forks.maxForks <workers>	Nombre maximal de processus pour exécuter les tests
--poolOptions.forks.minForks <workers>	Nombre minimal de processus pour exécuter les tests
--poolOptions.vmForks.isolate	Isoler les tests dans le pool de forks (par défaut: true)
--poolOptions.vmForks.singleFork	Exécuter les tests dans un seul child_process (par défaut: false)
--poolOptions.vmForks.maxForks <workers>	Nombre maximal de processus pour exécuter les tests
--poolOptions.vmForks.minForks <workers>	Nombre minimal de processus pour exécuter les tests
--poolOptions.vmForks.memoryLimit <limit>	Limite de mémoire pour le pool de forks VM. Si vous constatez des fuites de mémoire, essayez de modifier cette valeur.
--fileParallelism	Tous les fichiers de test doivent-ils s'exécuter en parallèle. Utilisez --no-file-parallelism pour désactiver (par défaut: true)
--maxWorkers <workers>	Nombre maximal de travailleurs pour exécuter les tests
--minWorkers <workers>	Nombre minimal de travailleurs pour exécuter les tests
--environment <name>	Spécifier l'environnement d'exécution, si l'exécution n'est pas dans le navigateur (par défaut: node)
--passWithNoTests	Réussir si aucun test n'est trouvé
--logHeapUsage	Afficher la taille du tas pour chaque test lors de l'exécution dans Node
--allowOnly	Autoriser les tests et les suites marqués comme only (par défaut: !process.env.CI)
--dangerouslyIgnoreUnhandledErrors	Ignorer toutes les erreurs non gérées qui se produisent
--shard <shards>	Partition de la suite de tests à exécuter au format <index>/<count>
--changed [since]	Exécuter les tests affectés par les fichiers modifiés (par défaut: false)
--sequence.shuffle.files	Exécuter les fichiers dans un ordre aléatoire. Les tests de longue durée ne commenceront pas plus tôt si vous activez cette option. (par défaut: false)
--sequence.shuffle.tests	Exécuter les tests dans un ordre aléatoire (par défaut: false)
--sequence.concurrent	Faire en sorte que les tests s'exécutent en parallèle (par défaut: false)
--sequence.seed <seed>	Définir la graine de randomisation. Cette option n'aura aucun effet si --sequence.shuffle est faux. Visitez la page "Random Seed" pour plus d'informations
--sequence.hooks <order>	Modifie l'ordre dans lequel les hooks sont exécutés. Les valeurs acceptées sont: "stack", "list" et "parallel". Visitez sequence.hooks pour plus d'informations (par défaut: "parallel")
--sequence.setupFiles <order>	Modifie l'ordre dans lequel les fichiers de configuration sont exécutés. Les valeurs acceptées sont: "list" et "parallel". Si elle est définie sur "list", exécutera les fichiers de configuration dans l'ordre dans lequel ils sont définis. Si elle est définie sur "parallel", exécutera les fichiers de configuration en parallèle (par défaut: "parallel")
--inspect [[host:]port]	Activer l'inspecteur Node.js (par défaut : 127.0.0.1:9229)
--inspectBrk [[host:]port]	Activer l'inspecteur Node.js et interrompre avant le début du test
--testTimeout <timeout>	Délai d'attente par défaut d'un test en millisecondes (par défaut : 5000)
--hookTimeout <timeout>	Délai d'attente par défaut d'un hook en millisecondes (par défaut : 10000)
--bail <number>	Arrêter l'exécution des tests lorsqu'un nombre donné de tests ont échoué (par défaut: 0)
--retry <times>	Réessayer le test un nombre de fois spécifique s'il échoue (par défaut : 0)
--diff <path>	Chemin vers une configuration de diff qui sera utilisée pour générer l'interface de diff
--exclude <glob>	Globs de fichiers supplémentaires à exclure des tests
--expandSnapshotDiff	Afficher la diff complète lorsque le snapshot échoue
--disableConsoleIntercept	Désactiver l'interception automatique de la journalisation de la console (par défaut: false)
--typecheck.enabled	Activer la vérification de type en parallèle des tests (par défaut: false)
--typecheck.only	Exécuter uniquement les tests de vérification de type. Cela active automatiquement la vérification de type (par défaut: false)
--typecheck.checker <name>	Spécifier le vérificateur de type à utiliser. Les valeurs disponibles sont: "tcs" et "vue-tsc" et un chemin vers un exécutable (par défaut: "tsc")
--typecheck.allowJs	Autoriser la vérification du type des fichiers JavaScript. Par défaut, prend la valeur de tsconfig.json
--typecheck.ignoreSourceErrors	Ignorer les erreurs de type des fichiers sources
--typecheck.tsconfig <path>	Chemin vers un fichier tsconfig personnalisé
--project <name>	Le nom du projet à exécuter si vous utilisez la fonctionnalité d'espace de travail Vitest. Cela peut être répété pour plusieurs projets : --project=1 --project=2. Vous pouvez également filtrer des projets à l'aide de caractères génériques comme --project=packages*
--slowTestThreshold <threshold>	Seuil en millisecondes pour qu'un test soit considéré comme lent (par défaut : 300)
--teardownTimeout <timeout>	Délai d'attente par défaut d'une fonction de démontage en millisecondes (par défaut: 10000)
--maxConcurrency <number>	Nombre maximal de tests simultanés dans une suite (par défaut: 5)
--run	Désactiver le mode surveillance
--segfaultRetry <times>	Réessayer la suite de tests si elle plante à cause d'un segfault (par défaut: true)
--no-color	Supprime les couleurs de la sortie de la console
--clearScreen	Effacer l'écran du terminal lors de la réexécution des tests en mode surveillance (par défaut: true)
--standalone	Démarrez Vitest sans exécuter les tests. Les filtres de fichiers seront ignorés, les tests ne seront exécutés qu'en cas de modification (par défaut : false)

TIP

Vitest prend en charge à la fois le camel case et le kebab case pour les arguments CLI. Par exemple, --passWithNoTests et --pass-with-no-tests fonctionneront tous les deux (--no-color et --inspect-brk sont les exceptions).

Vitest prend également en charge différentes façons de spécifier la valeur : --reporter dot et --reporter=dot sont tous les deux valides.

Si une option prend en charge un tableau de valeurs, vous devez passer l'option plusieurs fois :

vitest --reporter=dot --reporter=default

Les options booléennes peuvent être niées avec le préfixe no-. Spécifier la valeur comme false fonctionne également :

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

changed

• Type: boolean | string

• Default: false

  Exécute uniquement les tests sur les fichiers modifiés. Si aucune valeur n'est fournie, il exécute les tests sur les modifications non validées (y compris les modifications staged et unstaged).

  Pour exécuter des tests sur les modifications apportées lors du dernier commit, vous pouvez utiliser --changed HEAD~1. Vous pouvez également transmettre le hachage du commit (par exemple, --changed 09a9920) ou le nom de la branche (par exemple, --changed origin/develop).

  Lorsqu'il est utilisé avec la couverture de code, le rapport ne contiendra que les fichiers liés aux modifications.

  S'il est associé à l'option de configuration forceRerunTriggers, l'ensemble de la suite de tests sera exécuté si au moins l'un des fichiers répertoriés dans la liste forceRerunTriggers est modifié. Par défaut, les modifications apportées au fichier de configuration Vitest et à package.json relanceront toujours l'ensemble de la suite.

shard

• Type: string

• Default: disabled

  Fragment de la suite de tests à exécuter, au format <index>/<count>, où :

  • count est un entier positif, représentant le nombre total de fragments.
  • index est un entier positif, représentant l'index du fragment à exécuter.

  Cette commande divise tous les tests en count parties égales et n'exécute que ceux qui se trouvent dans la partie index. Par exemple, pour diviser votre suite de tests en trois parties, utilisez ceci :

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

WARNING

Vous ne pouvez pas utiliser cette option avec --watch activé (activé par défaut en dev).