Interface de Ligne de Commande

Commandes

vitest

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

Vous pouvez passer un argument supplémentaire comme filtre des fichiers de test à exécuter. Par exemple :

vitest foobar

Cela exécutera seulement le fichier de test qui contient foobar dans son chemin. Ce filtre vérifie uniquement l’inclusion et ne prend pas en charge les expressions régulières ou les modèles globaux (à moins que votre terminal ne le traite avant que Vitest ne reçoive le filtre).

vitest run

Effectue une exécution unique sans mode de surveillance.

vitest watch

Exécute tous les ensembles de tests mais surveille les changements et relance les tests lorsqu’ils changent. Même chose que d’appeler vitest sans argument. Passera à vitest run dans CI.

vitest dev

Alias pour vitest watch.

vitest related

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

Utile à exécuter avec lint-staged ou avec votre configuration CI.

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

Astuce

N’oubliez pas que Vitest s’exécute avec le mode de 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 des tests de performance, qui comparent les résultats de performance.

vitest init

vitest init <name> peut être utilisé pour configurer la configuration de projet. Pour le moment, cela ne prend en charge que la valeur browser :

vitest init browser

vitest list

La commande vitest list hérite de toutes les options de vitest pour imprimer la liste de tous les tests correspondants. Cette commande ignore l’option reporters. Par défaut, elle imprimera les noms de tous les tests qui correspondent au filtre de fichier et au modèle de nom :

vitest list filename.spec.ts -t="some-test"

describe > some-test
describe > some-test > test 1
describe > some-test > test 2

Vous pouvez passer le drapeau --json pour imprimer les tests au format JSON ou les enregistrer dans un fichier séparé :

vitest list filename.spec.ts -t="some-test" --json=./file.json

Si le drapeau --json ne reçoit pas de valeur, il sortira le JSON dans stdout.

Options

Astuce

Vitest prend en charge à la fois le camel case et le kebab case pour les arguments de la 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 manières de spécifier la valeur : --reporter dot et --reporter=dot sont tous deux valides.

Si l’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
• Par défaut : false

Exécute des tests uniquement sur les fichiers modifiés. Si aucune valeur n’est fournie, cela exécutera des tests sur les modifications non validées (y compris les changements en attente et non en attente).

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

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

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

shard

• Type : string
• Par défaut : désactivé

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

• count est un entier positif, le nombre de parties divisées
• index est un entier positif, l’index de la partie divisée

Cette commande divisera tous les tests en count parties égales et n’exécutera que ceux qui se trouvent dans une 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

Attention

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

Astuce

Si --reporter=blob est utilisé sans fichier de sortie, le chemin par défaut inclura la configuration de shard actuelle pour éviter les collisions avec d’autres processus Vitest.

merge-reports

• Type : boolean | string

Fusionne chaque rapport blob situé dans le dossier spécifié (.vitest-reports par défaut). Vous pouvez utiliser n’importe quel reporter avec cette commande (sauf blob) :

vitest --merge-reports --reporter=junit