Configuration de Vitest

Configuration

vitest lit le fichier racine vite.config.ts s'il est présent, afin de s'aligner sur les plugins et la configuration de votre application Vite. Si vous souhaitez une configuration différente pour les tests, ou si votre application principale ne repose pas sur Vite, vous avez les options suivantes :

Créer un fichier vitest.config.ts. Il aura la priorité et remplacera la configuration de vite.config.ts.
Transmettre l'option --config à la CLI, par exemple vitest --config ./path/to/vitest.config.ts.
Utiliser process.env.VITEST ou la propriété mode de defineConfig (définie sur test/benchmark si elle n'est pas remplacée) pour appliquer conditionnellement une configuration différente dans vite.config.ts.

Pour configurer vitest lui-même, ajoutez la propriété test dans votre configuration Vite. Vous devrez également ajouter une référence aux types de Vitest via une directive triple slash en haut de votre fichier de configuration, si vous importez defineConfig depuis vite.

Si vous utilisez defineConfig depuis vite, vous devez suivre les instructions suivantes :

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

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

Si vous utilisez defineConfig depuis vitest/config, vous devez suivre les instructions suivantes :

import { defineConfig } from 'vitest/config';

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

Vous pouvez obtenir les options par défaut de Vitest pour les étendre si nécessaire :

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

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

Lorsque vous utilisez un fichier vitest.config.js distinct, vous pouvez étendre les options de Vite à partir d'un autre fichier de configuration.

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

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

WARNING

La fonction mergeConfig est disponible dans Vitest depuis la version v0.30.0. Vous pouvez l'importer directement depuis vite si vous utilisez une version antérieure.

Si votre configuration Vite est définie sous forme de fonction, vous pouvez définir la configuration comme ceci :

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

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

Options

TIP

En plus des options suivantes, vous pouvez également utiliser n'importe quelle option de configuration de Vite. Par exemple, define pour définir des variables globales, ou resolve.alias pour définir des alias.

TIP

Toutes les options de configuration qui ne sont pas prises en charge dans un fichier de configuration de workspace sont signalées par *.

include

Type: string[]
Par défaut: ['**/*.{test,spec}.?(c|m)[jt]s?(x)']

Motifs glob des fichiers à inclure dans l'exécution des tests.

exclude

Type: string[]
Par défaut: ['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**', '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build}.config.*']

Motifs glob des fichiers à exclure de l'exécution des tests.

includeSource

Type: string[]
Par défaut: []

Motifs glob pour inclure les fichiers de test dans le code source.

Lorsqu'il est défini, Vitest exécutera tous les fichiers correspondants contenant import.meta.vitest.

server

Type: { sourcemap?, deps?, ... }
Version: Depuis Vitest 0.34.0

Options du serveur Vite.

server.sourcemap

Type: 'inline' | boolean
Par défaut: 'inline'

Injecter une source map en ligne dans les modules.

server.debug

Type: { dumpModules?, loadDumppedModules? }

Options du débogueur Vite-Node.

server.debug.dumpModules

Type: boolean | string

Enregistrer le module transformé dans le système de fichiers. Si une chaîne est fournie, l'enregistrement se fera vers le chemin spécifié.

server.debug.loadDumppedModules

Type: boolean

Lire le module enregistré depuis le système de fichiers s'il existe. Utile pour le débogage en modifiant le résultat de l'enregistrement dans le système de fichiers.

server.deps

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

Gestion des dépendances.

server.deps.external

Type: (string | RegExp)[]
Par défaut: [/\/node_modules\//]

Externaliser signifie que Vite ne traitera pas le package et le laissera à Node.js natif. Les dépendances externalisées ne seront pas soumises aux transformateurs et aux résolveurs de Vite, et ne prennent donc pas en charge HMR lors du rechargement. Par défaut, tous les packages dans node_modules sont externalisés.

Ces options prennent en charge les noms de package dans node_modules ou spécifiés dans deps.moduleDirectories. Par exemple, le package @company/some-name situé dans packages/some-name doit être spécifié comme some-name, et packages doit être inclus dans deps.moduleDirectories. En principe, Vitest vérifie toujours le chemin du fichier, pas le nom réel du package.

Si une expression régulière est utilisée, Vitest l'applique au chemin du fichier, pas au nom du package.

server.deps.inline

Type: (string | RegExp)[] | true
Par défaut: []

Forcer Vite à traiter les modules en ligne. Cela peut être utile pour gérer les packages qui livrent du .js au format ESM (que Node ne peut pas gérer).

Si true, chaque dépendance sera traitée en ligne. Toutes les dépendances spécifiées dans ssr.noExternal seront traitées en ligne par défaut.

server.deps.fallbackCJS

Type boolean
Par défaut: false

Lorsqu'une dépendance est un package ESM valide, tenter de déterminer la version CJS en fonction du chemin. Cela peut être utile si une dépendance a un fichier ESM incorrect.

Cela pourrait potentiellement entraîner un désalignement si un package a une logique différente en mode ESM et CJS.

server.deps.cacheDir

Type string
Par défaut: 'node_modules/.vite'

Répertoire pour enregistrer les fichiers de cache.

deps

Type: { optimizer?, registerNodeLoader?, ... }

Gestion de la résolution des dépendances.

deps.optimizer

Type: { ssr?, web? }
Version: Depuis Vitest 0.34.0
Voir aussi: Options d'optimisation des dépendances

Activer l'optimisation des dépendances. Si vous avez beaucoup de tests, cela pourrait améliorer leurs performances. Avant Vitest 0.34.0, cette option s'appelait deps.experimentalOptimizer.

Lorsque Vitest rencontre une bibliothèque externe listée dans include, elle est regroupée dans un seul fichier via esbuild et importée comme un module unique. C'est avantageux pour plusieurs raisons :

L'importation de packages comportant de nombreuses dépendances est une opération coûteuse en temps. En les regroupant dans un seul fichier, nous pouvons gagner beaucoup de temps.
L'importation de bibliothèques d'interface utilisateur est coûteuse car elles ne sont pas destinées à être exécutées à l'intérieur de Node.js.
Votre configuration alias est désormais prise en compte dans les packages regroupés.
Le code de vos tests s'exécute dans un environnement plus proche de celui du navigateur.

Notez que seuls les packages dans l'option deps.optimizer?.[mode].include sont regroupés (certains plugins remplissent cela automatiquement, comme Svelte). Vous pouvez en savoir plus sur les options disponibles dans la documentation Vite (Vitest ne prend pas en charge les options disable et noDiscovery). Par défaut, Vitest utilise optimizer.web pour les environnements jsdom et happy-dom, et optimizer.ssr pour les environnements node et edge, mais cela peut être configuré via transformMode.

Ces options héritent de votre configuration optimizeDeps (pour web, Vitest étendra optimizeDeps, pour ssr - ssr.optimizeDeps). Si vous redéfinissez l'option include/exclude dans deps.optimizer, elle étendra votre optimizeDeps lors de l'exécution des tests. Vitest supprime automatiquement les mêmes options de include, si elles sont répertoriées dans exclude.

TIP

Vous ne pourrez pas modifier le code de node_modules pour le débogage, car le code utilisé se trouve dans votre répertoire cacheDir ou test.cache.dir. Si vous souhaitez déboguer avec des instructions console.log, modifiez-le directement ou forcez le regroupement avec l'option deps.optimizer?.[mode].force.

deps.optimizer.{mode}.enabled

Type: boolean
Par défaut: true si vous utilisez >= Vite 4.3.2, false sinon

Activer l'optimisation des dépendances.

WARNING

Cette option ne fonctionne qu'avec Vite 4.3.2 ou supérieur.

deps.web

Type: { transformAssets?, ... }
Version: Depuis Vite 0.34.2

Options appliquées aux fichiers externes lorsque le mode de transformation est défini sur web. Par défaut, jsdom et happy-dom utilisent le mode web, tandis que les environnements node et edge utilisent le mode de transformation ssr. Ces options n'auront donc aucun effet sur les fichiers dans ces environnements.

En général, les fichiers dans node_modules sont externalisés, mais ces options affectent également les fichiers dans server.deps.external.

deps.web.transformAssets

Type: boolean
Par défaut: true

Vitest doit-il traiter les fichiers d'actifs (.png, .svg, .jpg, etc.) et les résoudre comme le ferait Vite dans un navigateur ?

Ce module aura une exportation par défaut égale au chemin d'accès à l'actif, si aucune requête n'est spécifiée.

WARNING

Pour le moment, cette option ne fonctionne qu'avec le pool experimentalVmThreads.

deps.web.transformCss

Type: boolean
Par défaut: true

Vitest doit-il traiter les fichiers CSS (.css, .scss, .sass, etc.) et les résoudre comme le fait Vite dans le navigateur ?

Si les fichiers CSS sont désactivés avec les options css, cette option ignorera simplement les erreurs ERR_UNKNOWN_FILE_EXTENSION.

WARNING

Pour le moment, cette option ne fonctionne qu'avec le pool experimentalVmThreads.

deps.web.transformGlobPattern

Type: RegExp | RegExp[]
Par défaut: []

Motif d'expression régulière pour faire correspondre les fichiers externes à transformer.

Par défaut, les fichiers dans node_modules sont externalisés et non transformés, sauf s'il s'agit de CSS ou d'un actif, et que l'option correspondante n'est pas désactivée.

WARNING

Pour le moment, cette option ne fonctionne qu'avec le pool experimentalVmThreads.

deps.registerNodeLoader*

Type: boolean
Par défaut: false

Utiliser le [chargeur Node expérimental] pour la résolution des importations dans les fichiers externalisés, en appliquant l'algorithme de résolution de Vite.

Si elle est désactivée, votre alias et <plugin>.resolveId n'affecteront pas les importations dans les packages externalisés (par défaut, node_modules).

deps.interopDefault

Type: boolean
Par défaut: true

Interpréter l'export par défaut des modules CJS comme des exports nommés. Certaines dépendances regroupent uniquement les modules CJS et n'utilisent pas les exportations nommées que Node.js peut analyser statiquement lorsqu'un package est importé à l'aide de la syntaxe import au lieu de require. Lors de l'importation de telles dépendances dans l'environnement Node à l'aide d'exportations nommées, vous verrez cette erreur :

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 ne fait pas d'analyse statique et ne peut pas échouer avant l'exécution de votre code. Vous verrez donc très probablement cette erreur lors de l'exécution des tests si cette fonctionnalité est désactivée :

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

Par défaut, Vitest suppose que vous utilisez un bundler pour contourner cela et ne plantera pas. Vous pouvez désactiver ce comportement manuellement si votre code n'est pas traité.

deps.moduleDirectories

Type: string[]
Par défaut: ['node_modules']

Liste des répertoires considérés comme des répertoires de modules. Cette option de configuration affecte le comportement de vi.mock : lorsqu'aucune factory n'est fournie et que le chemin de ce que vous simulez correspond à l'une des valeurs moduleDirectories, Vitest essaiera de résoudre la simulation en recherchant un dossier __mocks__ dans la racine du projet.

Cette option détermine aussi si un fichier doit être considéré comme un module lors de l'externalisation des dépendances. Par défaut, Vitest importe des modules externes avec Node.js natif en contournant l'étape de transformation de Vite.

La définition de cette option remplace la valeur par défaut. Si vous souhaitez toujours rechercher des packages dans node_modules, incluez-la avec toutes les autres options :

import { defineConfig } from 'vitest/config';

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

runner

Type: VitestRunnerConstructor
Par défaut: node, lors de l'exécution des tests, ou benchmark, lors de l'exécution des benchmarks

Chemin vers un exécuteur de tests personnalisé. Il s'agit d'une fonctionnalité avancée et doit être utilisée avec des exécuteurs de bibliothèque personnalisés. Vous pouvez en savoir plus à ce sujet dans la documentation.

benchmark

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

Options utilisées lors de l'exécution de vitest bench.

benchmark.include

Type: string[]
Par défaut: ['**/*.{bench,benchmark}.?(c|m)[jt]s?(x)']

Motifs glob des fichiers de test de benchmark à inclure.

benchmark.exclude

Type: string[]
Par défaut: ['node_modules', 'dist', '.idea', '.git', '.cache']

Motifs glob des fichiers de test de benchmark à exclure.

benchmark.includeSource

Type: string[]
Par défaut: []

Motifs glob pour inclure les fichiers de test de benchmark dans le code source. Cette option est similaire à includeSource.

Lorsqu'il est défini, Vitest exécutera tous les fichiers correspondants contenant import.meta.vitest.

benchmark.reporters

Type: Arrayable<BenchmarkBuiltinReporters | Reporter>
Par défaut: 'default'

Rapporteur personnalisé pour les résultats. Peut contenir un ou plusieurs noms de rapport intégrés, des instances de rapport et/ou des chemins d'accès à des rapporteurs personnalisés.

benchmark.outputFile

Type: string | Record<string, string>

Enregistrer les résultats du benchmark dans un fichier lorsque l'option --reporter=json est spécifiée. En fournissant un objet au lieu d'une chaîne, vous pouvez définir des sorties individuelles lors de l'utilisation de plusieurs rapporteurs.

Pour fournir un objet via une commande CLI, utilisez la syntaxe suivante : --outputFile.json=./path --outputFile.junit=./other-path.

alias

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

Définir des alias personnalisés lors de l'exécution des tests. Ils seront fusionnés avec les alias de resolve.alias.

globals

Type: boolean
Par défaut: false
CLI: --globals, --globals=false

Par défaut, vitest ne fournit pas d'API globales pour encourager l'utilisation explicite. Si vous préférez utiliser les API globalement comme avec Jest, vous pouvez passer l'option --globals à la CLI ou ajouter globals: true dans la configuration.

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

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

Pour TypeScript avec les API globales, ajoutez vitest/globals au champ types dans votre tsconfig.json

json

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

Si vous utilisez déjà unplugin-auto-import, vous pouvez également l'utiliser directement pour importer automatiquement ces API.

// 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

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

Définit l'environnement utilisé pour l'exécution des tests. Par défaut, Vitest utilise l'environnement Node.js. Pour les applications web, vous pouvez utiliser un environnement de type navigateur via jsdom ou happy-dom. Pour les fonctions Edge, l'environnement edge-runtime est disponible.

Vous pouvez spécifier un environnement différent pour un fichier de test en ajoutant un docblock @vitest-environment ou un commentaire en haut du fichier :

Format Docblock :

/**
 * @vitest-environment jsdom
 */

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

Format Commentaire :

// @vitest-environment happy-dom

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

Pour assurer la compatibilité avec Jest, @jest-environment est également pris en charge :

/**
 * @jest-environment jsdom
 */

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

Si Vitest est exécuté avec l'option --threads=false, les tests seront exécutés dans l'ordre suivant : node, jsdom, happy-dom, edge-runtime, puis les custom environments (environnements personnalisés). Les tests utilisant le même environnement seront regroupés et exécutés séquentiellement.

Depuis la version 0.23.0, vous pouvez définir des environnements personnalisés. Si un environnement non intégré est spécifié, Vitest tentera de charger le package vitest-environment-${name}. Ce package doit exporter un objet conforme à l'interface Environment :

import type { Environment } from 'vitest';

export default <Environment>{
  name: 'custom',
  transformMode: 'ssr',
  setup() {
    // Configuration personnalisée de l'environnement
    return {
      teardown() {
        // Appelé après l'exécution de tous les tests utilisant cet environnement
      },
    };
  },
};

Vitest expose également builtinEnvironments via le point d'entrée vitest/environments, si vous souhaitez simplement l'étendre. Pour plus d'informations, consultez notre guide sur l'extension des environnements.

environmentOptions

Type: Record<'jsdom' | string, unknown>
Default: {}

Ces options sont transmises à la méthode setup de l'environment courant. Par défaut, seules les options de JSDOM peuvent être configurées si vous l'utilisez comme environnement de test.

environmentMatchGlobs

Type: [string, EnvironmentName][]
Default: []

Permet d'assigner automatiquement un environnement en fonction de motifs glob. La première correspondance est utilisée.

Exemple :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environmentMatchGlobs: [
      // Tous les tests dans tests/dom seront exécutés dans jsdom
      ['tests/dom/**', 'jsdom'],
      // Tous les tests dans tests/ avec .edge.test.ts seront exécutés dans edge-runtime
      ['**/*.edge.test.ts', 'edge-runtime'],
      // ...
    ],
  },
});

poolMatchGlobs

Type: [string, 'threads' | 'child_process' | 'experimentalVmThreads'][]
Default: []
Version: Depuis Vitest 0.29.4

Permet d'assigner automatiquement le pool dans lequel les tests seront exécutés en fonction de motifs glob. La première correspondance est utilisée.

Exemple :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolMatchGlobs: [
      // Tous les tests dans le répertoire "worker-specific" seront exécutés dans un worker, comme si l'option `--threads` était activée.
      ['**/tests/worker-specific/**', 'threads'],
      // Exécuter tous les tests dans le répertoire "browser" dans un navigateur réel
      ['**/tests/browser/**', 'browser'],
      // Tous les autres tests seront exécutés en fonction des options "browser.enabled" et "threads", si aucun autre glob n'est spécifié.
      // ...
    ],
  },
});

update*

Type: boolean
Default: false
CLI: -u, --update, --update=false

Met à jour les fichiers de snapshot. Cela mettra à jour tous les snapshots modifiés et supprimera ceux qui sont obsolètes.

watch*

Type: boolean
Default: true
CLI: -w, --watch, --watch=false

Active le mode watch (surveillance).

root

Type: string
CLI: -r <path>, --root=<path>

Définit le répertoire racine du projet.

reporters*

Type: Reporter | Reporter[]
Default: 'default'
CLI: --reporter=<name>, --reporter=<name1> --reporter=<name2>

Permet de spécifier des reporters personnalisés pour la sortie des résultats. Les reporters peuvent être une instance de Reporter ou une chaîne de caractères pour sélectionner les reporters intégrés :

'default' - Replie les suites de tests réussies.
'basic' - Fournit un rapport similaire au rapport par défaut utilisé dans l'intégration continue.
'verbose' - Conserve l'arborescence complète des tâches visible.
'dot' - Affiche chaque tâche sous forme de point unique.
'junit' - Reporter JUnit XML (vous pouvez configurer le nom de la balise testsuites avec la variable d'environnement VITEST_JUNIT_SUITE_NAME, et la propriété de la balise classname avec VITEST_JUNIT_CLASSNAME).
'json' - Génère un simple résumé JSON.
'html' - Génère un rapport HTML basé sur @vitest/ui.
'hanging-process' - Affiche une liste des processus bloqués si Vitest ne parvient pas à quitter le processus en toute sécurité. Cette opération peut être coûteuse, ne l'activez que si Vitest ne quitte pas le processus de manière cohérente.
Chemin d'accès à un reporter personnalisé (par exemple, './path/to/reporter.ts', '@scope/reporter').

outputFile*

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

Écrit les résultats des tests dans un fichier lorsque l'option --reporter=json, --reporter=html ou --reporter=junit est également spécifiée. En fournissant un objet au lieu d'une chaîne, vous pouvez définir des sorties individuelles lorsque vous utilisez plusieurs reporters.

experimentalVmThreads

Type: boolean
CLI: --experimentalVmThreads, --experimental-vm-threads
Version: Depuis Vitest 0.34.0

Exécute les tests en utilisant le contexte VM (dans un environnement sandbox) dans un pool de workers.

Cela peut accélérer l'exécution des tests, mais le module VM est instable lors de l'exécution de code ESM. Vos tests risquent de provoquer des fuites de mémoire. Pour éviter cela, envisagez de modifier manuellement la valeur de experimentalVmWorkerMemoryLimit.

WARNING

L'exécution de code dans un sandbox présente des avantages (tests plus rapides), mais s'accompagne également d'inconvénients.

Les globales dans les modules natifs, tels que (fs, path, etc.), diffèrent des globales présentes dans votre environnement de test. Par conséquent, toute erreur levée par ces modules natifs fera référence à un constructeur d'erreur différent de celui utilisé dans votre code :

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

L'importation de modules ES les met en cache indéfiniment, ce qui introduit des fuites de mémoire si vous avez beaucoup de contextes (fichiers de test). Il n'existe pas d'API dans Node.js qui efface ce cache.
L'accès aux globales prend plus de temps dans un environnement sandbox.

Soyez conscient de ces problèmes lors de l'utilisation de cette option. L'équipe Vitest ne peut résoudre aucun de ces problèmes.

experimentalVmWorkerMemoryLimit

Type: string | number
CLI: --experimentalVmWorkerMemoryLimit, --experimental-vm-worker-memory-limit
Default: 1 / CPU Cores
Version: Depuis Vitest 0.34.0

Spécifie la limite de mémoire pour les workers avant qu'ils ne soient recyclés. Cette valeur dépend fortement de votre environnement. Il est donc préférable de la spécifier manuellement plutôt que de se fier à la valeur par défaut.

Cette option affecte uniquement les workers qui exécutent des tests dans un contexte VM.

TIP

L'implémentation est basée sur workerIdleMemoryLimit de Jest.

La limite peut être spécifiée de différentes manières et, quel que soit le résultat, Math.floor est utilisé pour la convertir en une valeur entière :

<= 1 - La valeur est considérée comme un pourcentage de la mémoire système. Par exemple, 0.5 définit la limite de mémoire du worker à la moitié de la mémoire système totale.
\> 1 - La valeur est considérée comme une valeur d'octet fixe. En raison de la règle précédente, si vous souhaitez une valeur de 1 octet (ce qui est peu probable), vous pouvez utiliser 1.1.
Avec des unités :
- 50% - Comme ci-dessus, un pourcentage de la mémoire système totale.
- 100KB, 65MB, etc. - Avec des unités pour indiquer une limite de mémoire fixe.
  - K / KB - Kilobytes (x1000)
  - KiB - Kibibytes (x1024)
  - M / MB - Megabytes
  - MiB - Mebibytes
  - G / GB - Gigabytes
  - GiB - Gibibytes

WARNING

La limite de mémoire basée sur le pourcentage ne fonctionne pas sur les workers Linux CircleCI en raison d'une mémoire système incorrecte signalée.

threads

Type: boolean
Default: true
CLI: --threads, --threads=false

Active le multi-threading en utilisant tinypool (un fork léger de Piscina). Avant Vitest 0.29.0, Vitest exécutait toujours les tests dans un thread de worker, même si cette option était désactivée. Depuis la version 0.29.0, si cette option est désactivée, Vitest utilise child_process pour créer un processus pour exécuter les tests, ce qui signifie que vous pouvez utiliser process.chdir et d'autres API qui n'étaient pas disponibles dans les workers. Si vous souhaitez revenir au comportement précédent, utilisez plutôt l'option --single-thread.

La désactivation de cette option entraîne l'exécution de tous les tests dans plusieurs processus enfants.

singleThread

Type: boolean
Default: false
Version: Depuis Vitest 0.29.0

Exécute tous les tests avec le même environnement dans un seul thread de worker. Cela désactivera l'isolation des modules intégrée (votre code source ou le code intégré sera toujours réévalué pour chaque test), mais peut améliorer les performances des tests. Avant Vitest 0.29.0, cela équivalait à utiliser --no-threads.

WARNING

Bien que cette option force l'exécution séquentielle des tests, elle est différente de --runInBand de Jest. Vitest utilise des workers non seulement pour exécuter les tests en parallèle, mais aussi pour fournir une isolation. En désactivant cette option, vos tests s'exécuteront séquentiellement, mais dans le même contexte global, vous devez donc fournir l'isolation vous-même.

Cela peut causer des problèmes si vous vous fiez à l'état global (ce que font généralement les frameworks frontend) ou si votre code s'appuie sur l'environnement pour être défini séparément pour chaque test. Cependant, cela peut accélérer vos tests (jusqu'à 3 fois plus vite) si ceux-ci ne dépendent pas de l'état global ou peuvent facilement le contourner.

maxThreads*

Type: number
Default: Nombre de cœurs CPU disponibles

Nombre maximum de threads. Vous pouvez également utiliser la variable d'environnement VITEST_MAX_THREADS.

minThreads*

Type: number
Default: Nombre de cœurs CPU disponibles

Nombre minimum de threads. Vous pouvez également utiliser la variable d'environnement VITEST_MIN_THREADS.

useAtomics*

Type: boolean
Default: false
Version: Depuis Vitest 0.28.3

Utilise 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.

testTimeout

Type: number
Default: 5000
CLI: --test-timeout=5000

Délai d'attente par défaut pour un test, en millisecondes.

hookTimeout

Type: number
Default: 10000

Délai d'attente par défaut pour un hook, en millisecondes.

teardownTimeout*

Type: number
Default: 10000

Délai d'attente par défaut pour la fermeture de Vitest à l'arrêt, en millisecondes.

silent*

Type: boolean
Default: false
CLI: --silent, --silent=false

Supprime la sortie de la console des tests.

setupFiles

Type: string | string[]

Chemin d'accès aux fichiers de configuration (setup files). Ils seront exécutés avant chaque fichier de test.

INFO

La modification des fichiers de configuration (setup files) déclenchera une nouvelle exécution de tous les tests.

Vous pouvez utiliser process.env.VITEST_POOL_ID (chaîne de caractères de type entier) à l'intérieur pour distinguer les threads (sera toujours '1' si exécuté avec threads: false).

TIP

Notez que si vous exécutez --threads=false, ce fichier de configuration sera exécuté plusieurs fois dans la même portée globale. Cela signifie que vous accédez au même objet global avant chaque test, assurez-vous donc de ne pas faire la même chose plus que nécessaire.

Par exemple, vous pouvez vous fier à une variable globale :

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

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

// Les hooks sont réinitialisés avant chaque suite
afterEach(() => {
  cleanup();
});

globalThis.resetBeforeEachTest = true;

globalSetup

Type: string | string[]

Chemin d'accès aux fichiers de configuration globale (global setup), relatif à la racine du projet.

Un fichier de configuration globale (global setup) peut soit exporter des fonctions nommées setup et teardown, soit une fonction default qui renvoie une fonction de démontage (exemple).

INFO

Plusieurs fichiers globalSetup sont possibles. Les fonctions setup et teardown sont exécutées séquentiellement, avec teardown dans l'ordre inverse.

WARNING

Sachez que la configuration globale est exécutée dans une portée globale différente, de sorte que vos tests n'ont pas accès aux variables définies ici.

watchExclude*

Type: string[]
Default: ['**/node_modules/**', '**/dist/**']

Motif Glob des chemins de fichiers à ignorer pour ne pas déclencher la réexécution de la surveillance.

forceRerunTriggers*

Type: string[]
Default: ['**/package.json/**', '**/vitest.config.*/**', '**/vite.config.*/**']

Motif Glob des chemins de fichiers qui relanceront toute la suite de tests. Combiné à l'argument --changed, cela exécutera toute la suite de tests si le déclencheur est trouvé dans le diff git.

Utile si vous testez l'appel de commandes CLI, car Vite ne peut pas construire un graphe de modules :

test('execute a script', async () => {
  // Vitest ne peut pas réexécuter ce test si le contenu de `dist/index.js` change
  await execa('node', ['dist/index.js']);
});

TIP

Assurez-vous que vos fichiers ne sont pas exclus par watchExclude.

isolate

Type: boolean
Par défaut: true
CLI: --isolate, --isolate=false

Isole l'environnement pour chaque fichier de test. Ne fonctionne pas si vous désactivez --threads.

Cette option n'affecte pas experimentalVmThreads.

coverage*

Vous pouvez utiliser v8, istanbul ou une solution de couverture personnalisée pour la collecte de la couverture.

Vous pouvez spécifier les options de couverture via la CLI en utilisant la notation par points :

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

WARNING

Si vous utilisez la notation par points pour les options de couverture, assurez-vous de spécifier --coverage.enabled. N'utilisez pas une seule option --coverage dans ce cas.

coverage.provider

Type: 'v8' | 'istanbul' | 'custom'
Par défaut: 'v8'
CLI: --coverage.provider=<provider>

Sélectionne l'outil de collecte de la couverture.

coverage.enabled

Type: boolean
Par défaut: false
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.enabled, --coverage.enabled=false

Active la collecte de la couverture. Peut être remplacée par l'option CLI --coverage.

coverage.include

Type: string[]
Par défaut: ['**']
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.include=<path>, --coverage.include=<path1> --coverage.include=<path2>

Liste des fichiers à inclure dans le calcul de la couverture, spécifiés par des motifs globaux.

coverage.extension

Type: string | string[]
Par défaut: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.cts', '.tsx', '.jsx', '.vue', '.svelte']
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.extension=<extension>, --coverage.extension=<extension1> --coverage.extension=<extension2>

coverage.exclude

Type: string[]
Par défaut:

[
  '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}',
];

Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.exclude=<path>, --coverage.exclude=<path1> --coverage.exclude=<path2>

Liste des fichiers à exclure du calcul de la couverture, spécifiés par des motifs globaux.

coverage.all

Type: boolean
Par défaut: false
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.all, --coverage.all=false

Indique si tous les fichiers, y compris ceux qui ne sont pas couverts par les tests, doivent être inclus dans le rapport.

coverage.clean

Type: boolean
Par défaut: true
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.clean, --coverage.clean=false

Supprime les résultats de la couverture précédents avant d'exécuter les tests.

coverage.cleanOnRerun

Type: boolean
Par défaut: true
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.cleanOnRerun, --coverage.cleanOnRerun=false

Supprime le rapport de couverture lors d'une nouvelle exécution en mode surveillance.

coverage.reportsDirectory

Type: string
Par défaut: './coverage'
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.reportsDirectory=<path>

Répertoire dans lequel les rapports de couverture sont écrits.

coverage.reporter

Type: string | string[] | [string, {}][]
Par défaut: ['text', 'html', 'clover', 'json']
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.reporter=<reporter>, --coverage.reporter=<reporter1> --coverage.reporter=<reporter2>

Reporters de couverture à utiliser. Consultez la documentation d'istanbul pour une liste détaillée de tous les reporters. Consultez @types/istanbul-reporter pour plus de détails sur les options spécifiques aux reporters.

Il existe trois façons de configurer les reporters :

Un seul reporter : { reporter: 'html' }
Plusieurs reporters sans options : { reporter: ['html', 'json'] }

Un ou plusieurs reporters avec des options :

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

Depuis Vitest 0.31.0, vous pouvez consulter votre rapport de couverture dans l'interface utilisateur de Vitest : consultez Vitest UI Coverage pour plus de détails.

coverage.reportOnFailure

Type: boolean
Par défaut: false (depuis Vitest 0.34.0)
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.reportOnFailure, --coverage.reportOnFailure=false
Version: Depuis Vitest 0.31.2

Génère un rapport de couverture même si les tests échouent.

coverage.allowExternal

Type: boolean
Par défaut: false
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.allowExternal, --coverage.allowExternal=false

Collecte la couverture des fichiers situés en dehors de la racine du projet (root).

coverage.skipFull

Type: boolean
Par défaut: false
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.skipFull, --coverage.skipFull=false

Ne pas afficher les fichiers ayant une couverture à 100 % des instructions, des branches et des fonctions.

coverage.perFile

Type: boolean
Par défaut: false
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.perFile, --coverage.perFile=false

Vérifie les seuils de couverture par fichier. Consultez les options lines (lignes), functions (fonctions), branches (branches) et statements (instructions) pour connaître les seuils réels.

coverage.thresholdAutoUpdate

Type: boolean
Par défaut: false
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.thresholdAutoUpdate=<boolean>

Met à jour les valeurs de seuil lines (lignes), functions (fonctions), branches (branches) et statements (instructions) dans le fichier de configuration lorsque la couverture actuelle est supérieure aux seuils configurés. Cette option permet de maintenir les seuils à jour lorsque la couverture s'améliore.

coverage.lines

Type: number
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.lines=<number>

Seuil pour la couverture des lignes. Voir documentation d'istanbul pour plus d'informations.

coverage.functions

Type: number
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.functions=<number>

Seuil pour la couverture des fonctions. Voir documentation d'istanbul pour plus d'informations.

coverage.branches

Type: number
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.branches=<number>

Seuil pour la couverture des branches. Voir documentation d'istanbul pour plus d'informations.

coverage.statements

Type: number
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.statements=<number>

Seuil pour la couverture des instructions. Voir documentation d'istanbul pour plus d'informations.

coverage.100

Type: boolean
Par défaut: false
Disponible pour les fournisseurs: 'v8' | 'istanbul'
CLI: --coverage.100, --coverage.100=false

Raccourci équivalent à --coverage.lines 100 --coverage.functions 100 --coverage.branches 100 --coverage.statements 100.

coverage.ignoreClassMethods

Type: string[]
Par défaut: []
Disponible pour les fournisseurs: 'istanbul'
CLI: --coverage.ignoreClassMethods=<method>

Définit un tableau de noms de méthodes de classe à ignorer pour le calcul de la couverture. Voir documentation d'istanbul pour plus d'informations.

coverage.watermarks

Type:

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

Par défaut:

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

Disponible pour les fournisseurs: 'v8' | 'istanbul'

Seuils de qualité (watermarks) pour les instructions, les lignes, les branches et les fonctions. Voir documentation d'istanbul pour plus d'informations.

coverage.customProviderModule

Type: string
Disponible pour les fournisseurs: 'custom'
CLI: --coverage.customProviderModule=<path or module name>

Spécifie le nom du module ou le chemin d'accès au module du fournisseur de couverture personnalisé. Voir Guide - Fournisseur de couverture personnalisé pour plus d'informations.

testNamePattern*

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

Exécute les tests dont le nom complet correspond au motif spécifié. Si vous ajoutez OnlyRunThis à cette propriété, seuls les tests dont le nom contient le mot OnlyRunThis seront exécutés. Les autres seront ignorés.

import { expect, test } from 'vitest';

// Sera exécuté
test('OnlyRunThis', () => {
  expect(true).toBe(true);
});

// Sera ignoré
test('doNotRun', () => {
  expect(true).toBe(true);
});

open*

Type: boolean
Par défaut: false
CLI: --open, --open=false

Ouvre l'interface utilisateur de Vitest (en cours de développement).

api

Type: boolean | number
Par défaut: false
CLI: --api, --api.port, --api.host, --api.strictPort

Démarre un serveur API sur un port spécifié. Si défini sur true, le port par défaut est 51204.

browser

Type: { enabled?, name?, provider?, headless?, api?, slowHijackESM? }
Par défaut: { enabled: false, headless: process.env.CI, api: 63315 }
Version: Depuis Vitest 0.29.4
CLI: --browser, --browser=<name>, --browser.name=chrome --browser.headless

Exécute les tests de Vitest dans un navigateur. Par défaut, WebdriverIO est utilisé, mais vous pouvez configurer un autre fournisseur avec l'option browser.provider.

NOTE

Pour en savoir plus sur les tests dans un navigateur réel, consultez la page du guide.

WARNING

C'est une fonctionnalité expérimentale. Les changements importants peuvent ne pas suivre la gestion sémantique des versions (semver). Il est recommandé d'épingler la version de Vitest lorsque vous l'utilisez.

browser.enabled

Type: boolean
Par défaut: false
CLI: --browser, --browser.enabled=false

Active l'exécution de tous les tests dans un navigateur par défaut. Peut être remplacé par l'option poolMatchGlobs.

browser.name

Type: string
CLI: --browser=safari

Exécute tous les tests dans un navigateur spécifique. Les options possibles varient selon le fournisseur :

webdriverio: firefox, chrome, edge, safari
playwright: firefox, webkit, chromium
custom: toute chaîne qui sera transmise au fournisseur

browser.headless

Type: boolean
Par défaut: process.env.CI
CLI: --browser.headless, --brower.headless=false

Exécute le navigateur en mode headless (sans interface graphique). Est activé par défaut dans un environnement d'intégration continue (CI).

browser.api

Type: number | { port?, strictPort?, host? }
Par défaut: 63315
CLI: --browser.api=63315, --browser.api.port=1234, --browser.api.host=example.com

Configure les options du serveur Vite qui sert le code dans le navigateur. N'affecte pas l'option test.api.

browser.provider

Type: 'webdriverio' | 'playwright' | string
Par défaut: 'webdriverio'
CLI: --browser.provider=playwright

Chemin d'accès au fournisseur qui sera utilisé lors de l'exécution des tests dans le navigateur. Vitest fournit deux fournisseurs : webdriverio (par défaut) et playwright. Les fournisseurs personnalisés doivent être exportés en utilisant l'exportation default et avoir la structure suivante :

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

Il s'agit d'une API avancée destinée aux auteurs de bibliothèques. Si vous souhaitez simplement exécuter des tests dans un navigateur, utilisez l'option browser.

browser.slowHijackESM

Type: boolean
Default: true
Version: Depuis Vitest 0.31.0

Lors de l'exécution de tests dans Node.js, Vitest peut utiliser sa propre résolution de modules pour simuler facilement des modules avec la syntaxe vi.mock. Cependant, il est difficile de reproduire la résolution des modules ES dans le navigateur. Par conséquent, vos fichiers sources doivent être transformés avant de pouvoir être utilisés par le navigateur.

Cette option n'a aucun effet sur les tests exécutés dans Node.js.

Elle est activée par défaut dans un environnement navigateur. Si vous n'utilisez pas vi.spyOn pour espionner les modules ES et que vous n'utilisez pas vi.mock, vous pouvez désactiver cette option pour améliorer légèrement les performances.

clearMocks

Type: boolean
Default: false

Appelle la méthode .mockClear() sur tous les espions avant chaque test. Cela efface l'historique des mocks, mais ne réinitialise pas leur implémentation à la valeur par défaut.

mockReset

Type: boolean
Default: false

Appelle la méthode .mockReset() sur tous les espions avant chaque test. Cela efface l'historique des mocks et réinitialise leur implémentation à une fonction vide (renvoyant undefined).

restoreMocks

Type: boolean
Default: false

Appelle la méthode .mockRestore() sur tous les espions avant chaque test. Cela efface l'historique des mocks et réinitialise leur implémentation à l'originale.

unstubEnvs

Type: boolean
Default: false
Version: Depuis Vitest 0.26.0

Appelle la méthode vi.unstubAllEnvs avant chaque test.

unstubGlobals

Type: boolean
Default: false
Version: Depuis Vitest 0.26.0

Appelle la méthode vi.unstubAllGlobals avant chaque test.

testTransformMode

Type: { web?, ssr? }
Version: Depuis Vitest 0.34.0

Détermine la méthode de transformation pour tous les modules importés dans un test correspondant au modèle glob. Par défaut, le comportement dépend de l'environnement. Par exemple, les tests avec l'environnement JSDOM traiteront tous les fichiers avec l'indicateur ssr: false, et les tests avec l'environnement Node traiteront tous les modules avec ssr: true.

testTransformMode.ssr

Type: string[]
Default: []

Utilise le pipeline de transformation SSR pour tous les modules dans les tests spécifiés.
Les plugins Vite recevront l'indicateur ssr: true lors du traitement de ces fichiers.

testTransformMode.web

Type: string[]
Default: []

Effectue d'abord un pipeline de transformation normal (ciblant le navigateur), puis effectue une réécriture SSR pour exécuter le code dans Node.
Les plugins Vite recevront l'indicateur ssr: false lors du traitement de ces fichiers.

snapshotFormat*

Type: PrettyFormatOptions

Options de format pour les tests de snapshot. Ces options sont transmises à pretty-format.

resolveSnapshotPath*

Type: (testPath: string, snapExtension: string) => string
Default: enregistre les snapshots dans le dossier __snapshots__

Remplace le chemin de snapshot par défaut. Par exemple, pour stocker les snapshots à côté des fichiers de test :

import { defineConfig } from 'vitest/config';

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

allowOnly

Type: boolean
Default: false
CLI: --allowOnly, --allowOnly=false

Autorise l'exécution des tests et des suites marqués comme "uniquement" (only).

dangerouslyIgnoreUnhandledErrors*

Type: boolean
Default: false
CLI: --dangerouslyIgnoreUnhandledErrors --dangerouslyIgnoreUnhandledErrors=false

Ignore toutes les erreurs non gérées qui se produisent. Attention : Cette option est déconseillée.

passWithNoTests*

Type: boolean
Default: false
CLI: --passWithNoTests, --passWithNoTests=false

Indique à Vitest de ne pas échouer si aucun test n'est trouvé.

logHeapUsage

Type: boolean
Default: false
CLI: --logHeapUsage, --logHeapUsage=false

Affiche l'utilisation du tas (heap) après chaque test, ce qui est utile pour déboguer les fuites de mémoire.

css

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

Configure le traitement du CSS. Lorsqu'ils sont exclus, les fichiers CSS seront remplacés par des chaînes vides pour éviter tout traitement ultérieur. Les modules CSS renverront un proxy pour ne pas affecter l'exécution.

css.include

Type: RegExp | RegExp[]
Default: []

Modèle RegExp pour les fichiers qui doivent renvoyer du CSS réel et être traités par le pipeline Vite.

TIP

Pour traiter tous les fichiers CSS, utilisez /.+/.

css.exclude

Type: RegExp | RegExp[]
Default: []

Modèle RegExp pour les fichiers qui renverront un fichier CSS vide.

css.modules

Type: { classNameStrategy? }
Default: {}

css.modules.classNameStrategy

Type: 'stable' | 'scoped' | 'non-scoped'
Default: 'stable'

Si vous choisissez de traiter les fichiers CSS, vous pouvez configurer si les noms de classe à l'intérieur des modules CSS doivent être "scopés" (limités à la portée du module). Vous pouvez choisir l'une des options suivantes :

stable : les noms de classe seront générés sous la forme _${name}_${hashedFilename}. La classe générée restera la même si le contenu CSS est modifié, mais changera si le nom du fichier est modifié ou si le fichier est déplacé vers un autre dossier. Ce paramètre est utile si vous utilisez la fonctionnalité de snapshot.
scoped : les noms de classe seront générés comme d'habitude, en respectant la méthode css.modules.generateScopeName, si vous en avez une et que le traitement CSS est activé. Par défaut, le nom de fichier sera généré sous la forme _${name}_${hash}, où le hachage inclut le nom de fichier et le contenu du fichier.
non-scoped : les noms de classe ne seront pas hachés.

WARNING

Par défaut, Vitest exporte un proxy, contournant le traitement des modules CSS. Si vous comptez sur les propriétés CSS de vos classes, vous devez activer le traitement CSS à l'aide de l'option include.

maxConcurrency

Type: number
Default: 5

Nombre maximal de tests marqués avec test.concurrent autorisés à s'exécuter simultanément.

Les tests dépassant cette limite seront mis en file d'attente et exécutés lorsqu'un emplacement deviendra disponible.

cache*

Type: false | { dir? }

Options pour configurer la politique de cache de Vitest. Actuellement, Vitest stocke le cache des résultats de test pour exécuter en priorité les tests les plus longs et ceux qui ont échoué.

cache.dir

Type: string
Default: node_modules/.vitest

Chemin d'accès au répertoire du cache.

sequence

Type: { sequencer?, shuffle?, seed?, hooks?, setupFiles? }

Options pour déterminer l'ordre d'exécution des tests.

Vous pouvez fournir des options de séquence à la CLI avec la notation pointée :

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

sequence.sequencer*

Type: TestSequencerConstructor
Default: BaseSequencer

Une classe personnalisée qui définit des méthodes pour le partitionnement (sharding) et le tri. Vous pouvez étendre BaseSequencer à partir de vitest/node si vous n'avez besoin de redéfinir qu'une des méthodes sort et shard, mais les deux doivent exister.

Le partitionnement (sharding) se fait avant le tri, et uniquement si l'option --shard est fournie.

sequence.shuffle

Type: boolean
Default: false
CLI: --sequence.shuffle, --sequence.shuffle=false

Si vous souhaitez exécuter les tests de manière aléatoire, vous pouvez activer cette option ou utiliser l'argument CLI --sequence.shuffle.

Vitest utilise généralement le cache pour trier les tests, ce qui permet aux tests de longue durée de démarrer plus tôt et d'accélérer l'exécution globale. Si vos tests s'exécutent dans un ordre aléatoire, vous perdrez cette amélioration des performances, mais cela peut être utile pour identifier les tests qui dépendent accidentellement d'une exécution précédente.

sequence.concurrent

Type: boolean
Default: false
CLI: --sequence.concurrent, --sequence.concurrent=false
Version: Depuis Vitest 0.32.2

Pour exécuter les tests en parallèle, activez cette option ou utilisez l'argument CLI --sequence.concurrent.

sequence.seed*

Type: number
Default: Date.now()
CLI: --sequence.seed=1000

Définit la graine (seed) pour la randomisation, si les tests s'exécutent dans un ordre aléatoire.

sequence.hooks

Type: 'stack' | 'list' | 'parallel'
Default: 'parallel'
CLI: --sequence.hooks=<value>

Modifie l'ordre d'exécution des hooks.

stack ordonnera les hooks "after" dans l'ordre inverse, les hooks "before" s'exécuteront dans l'ordre dans lequel ils ont été définis
list ordonnera tous les hooks dans l'ordre dans lequel ils sont définis
parallel exécutera les hooks dans un seul groupe en parallèle (les hooks dans les suites parentes s'exécuteront toujours avant les hooks de la suite actuelle)

sequence.setupFiles

Type: 'list' | 'parallel'
Default: 'parallel'
CLI: --sequence.setupFiles=<value>
Version: Depuis Vitest 0.29.3

Modifie l'ordre dans lequel les fichiers de configuration sont exécutés.

list exécutera les fichiers de configuration dans l'ordre dans lequel ils sont définis
parallel exécutera les fichiers de configuration en parallèle

typecheck

Options pour configurer l'environnement de test de vérification de type.

typecheck.checker

Type: 'tsc' | 'vue-tsc' | string
Default: tsc

Outil à utiliser pour la vérification de type. Vitest lancera un processus avec des paramètres spécifiques pour faciliter l'analyse, en fonction du type. Le vérificateur doit implémenter le même format de sortie que tsc.

Vous devez avoir un package installé pour utiliser le vérificateur de type :

tsc nécessite le package typescript
vue-tsc nécessite le package vue-tsc

Vous pouvez également transmettre un chemin vers un binaire personnalisé ou un nom de commande qui produit la même sortie que tsc --noEmit --pretty false.

typecheck.include

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

Modèle glob pour les fichiers qui doivent être traités comme des fichiers de test.

typecheck.exclude

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

Modèle glob pour les fichiers qui ne doivent pas être traités comme des fichiers de test.

typecheck.allowJs

Type: boolean
Default: false

Vérifie les fichiers JS qui ont le commentaire @ts-check. Si vous l'avez activé dans tsconfig, cela ne le remplacera pas.

typecheck.ignoreSourceErrors

Type: boolean
Default: false

Empêche l'échec des tests si Vitest trouve des erreurs en dehors des fichiers de test. Cela masquera complètement les erreurs non liées aux tests.

Par défaut, si Vitest trouve une erreur de source, la suite de tests échouera.

typecheck.tsconfig

Type: string
Default: Tente de trouver le fichier tsconfig.json le plus proche

Chemin d'accès à un fichier tsconfig personnalisé, relatif à la racine du projet.

slowTestThreshold*

Type: number
Default: 300

Le nombre de millisecondes après lequel un test est considéré comme lent et signalé comme tel dans les résultats.

chaiConfig

Type: { includeStack?, showDiff?, truncateThreshold? }
Default: { includeStack: false, showDiff: true, truncateThreshold: 40 }
Version: Depuis Vitest 0.30.0

Équivalent à la configuration de Chai.

chaiConfig.includeStack

Type: boolean
Default: false

Détermine si la trace de la pile est incluse dans le message d'erreur Assertion. La valeur par défaut de false supprime la trace de la pile dans le message d'erreur.

chaiConfig.showDiff

Type: boolean
Default: true

Détermine si l'indicateur showDiff doit être inclus ou non dans les AssertionErrors lancés. false sera toujours false ; true sera true lorsque l'assertion a demandé qu'une différence soit affichée.

chaiConfig.truncateThreshold

Type: number
Default: 40

Définit le seuil de longueur des valeurs réelles et attendues dans les messages d'erreur d'assertion. Si ce seuil est dépassé, par exemple pour les grandes structures de données, la valeur est remplacée par quelque chose comme [ Array(3) ] ou { Object (prop1, prop2) }. Définissez-le sur 0 si vous voulez désactiver complètement la troncature.

Cette option de configuration affecte la troncature des valeurs dans les titres test.each et à l'intérieur du message d'erreur d'assertion.

bail

Type: number
Default: 0
CLI: --bail=<value>
Version: Depuis Vitest 0.31.0

Arrête l'exécution des tests lorsqu'un nombre donné de tests ont échoué.

Par défaut, Vitest exécute tous les cas de test, même si certains échouent. Cela peut être indésirable pour les builds CI où seul un taux de réussite de 100 % est requis, et où l'exécution des tests doit être interrompue dès qu'une erreur se produit. L'option bail peut être utilisée pour accélérer les exécutions CI en empêchant l'exécution de tests supplémentaires lorsque des échecs se sont produits.

retry

Type: number
Default: 0
CLI: --retry=<value>
Version: Depuis Vitest 0.32.3

Réessaie le test un nombre de fois spécifique s'il échoue.

onConsoleLog

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

Gestionnaire personnalisé pour console.log dans les tests. Si vous renvoyez false, Vitest n'affichera pas le journal dans la console.

Peut être utile pour filtrer les logs des bibliothèques tierces.

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

Type: string
CLI: --diff=<value>
Version: Depuis Vitest 0.34.5

Chemin d'accès à un fichier de configuration de diff qui sera utilisé pour générer l'interface de comparaison. Utile pour personnaliser l'affichage de la comparaison.

vitest.diff.tsvitest.config.js

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

export default {
  aIndicator: c.bold('--'), // Indiqueur pour la partie "a" (avant) de la diff
  bIndicator: c.bold('++'), // Indiqueur pour la partie "b" (après) de la diff
  omitAnnotationLines: true, // Ignorer les lignes d'annotation
} satisfies DiffOptions;

import { defineConfig } from 'vitest/config';

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

Configuration de Vitest ​

Configuration ​

Options ​

include ​

exclude ​

includeSource ​

server ​

server.sourcemap ​

server.debug ​

server.debug.dumpModules ​

server.debug.loadDumppedModules ​

server.deps ​

server.deps.external ​

server.deps.inline ​

server.deps.fallbackCJS ​

server.deps.cacheDir ​

deps ​

deps.optimizer ​

deps.optimizer.{mode}.enabled ​

deps.web ​

deps.web.transformAssets ​

deps.web.transformCss ​

deps.web.transformGlobPattern ​

deps.registerNodeLoader* ​

deps.interopDefault ​

deps.moduleDirectories ​

runner ​

benchmark ​

benchmark.include ​

benchmark.exclude ​

benchmark.includeSource ​

benchmark.reporters ​

benchmark.outputFile ​

alias ​

globals ​

environment ​

environmentOptions ​

environmentMatchGlobs ​

poolMatchGlobs ​

update* ​

watch* ​

root ​

reporters* ​

outputFile* ​

experimentalVmThreads ​

experimentalVmWorkerMemoryLimit ​

threads ​

singleThread ​

maxThreads* ​

minThreads* ​

useAtomics* ​

testTimeout ​

hookTimeout ​

teardownTimeout* ​

silent* ​

setupFiles ​

globalSetup ​

watchExclude* ​

forceRerunTriggers* ​

isolate ​

coverage* ​

coverage.provider ​

coverage.enabled ​

coverage.include ​

coverage.extension ​

coverage.exclude ​

coverage.all ​

coverage.clean ​

coverage.cleanOnRerun ​

coverage.reportsDirectory ​

coverage.reporter ​

coverage.reportOnFailure ​

coverage.allowExternal ​

coverage.skipFull ​

coverage.perFile ​

coverage.thresholdAutoUpdate ​

coverage.lines ​

coverage.functions ​

coverage.branches ​

coverage.statements ​

Configuration de Vitest

Configuration

Options

include

exclude

includeSource

server

server.sourcemap

server.debug

server.debug.dumpModules

server.debug.loadDumppedModules

server.deps

server.deps.external

server.deps.inline

server.deps.fallbackCJS

server.deps.cacheDir

deps

deps.optimizer

deps.optimizer.{mode}.enabled

deps.web

deps.web.transformAssets

deps.web.transformCss

deps.web.transformGlobPattern

deps.registerNodeLoader*

deps.interopDefault

deps.moduleDirectories

runner

benchmark

benchmark.include

benchmark.exclude

benchmark.includeSource

benchmark.reporters

benchmark.outputFile

alias

globals

environment

environmentOptions

environmentMatchGlobs

poolMatchGlobs

update*

watch*

root

reporters*

outputFile*

experimentalVmThreads

experimentalVmWorkerMemoryLimit

threads

singleThread

maxThreads*

minThreads*

useAtomics*

testTimeout

hookTimeout

teardownTimeout*

silent*

setupFiles

globalSetup

watchExclude*

forceRerunTriggers*

isolate

coverage*

coverage.provider

coverage.enabled

coverage.include

coverage.extension

coverage.exclude

coverage.all

coverage.clean

coverage.cleanOnRerun

coverage.reportsDirectory

coverage.reporter

coverage.reportOnFailure

coverage.allowExternal

coverage.skipFull

coverage.perFile

coverage.thresholdAutoUpdate

coverage.lines

coverage.functions

coverage.branches

coverage.statements