Configuration de Vitest

Pour créer un fichier de configuration Vitest, suivez le guide. Assurez-vous de comprendre le fonctionnement de la résolution de configuration de Vitest avant de continuer.

WARNING

Toutes les options listées ici se trouvent dans une propriété test à l'intérieur de la configuration :

export default defineConfig({
  test: {
    exclude: [],
  },
});

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.

Toutes les options de configuration qui ne sont pas prises en charge dans un projet d'espace de travail ont le signe * à côté d'elles.

include

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

Liste de motifs glob correspondant à vos fichiers de test.

REMARQUE

Lors de l'utilisation de la couverture, Vitest ajoute automatiquement les motifs include des fichiers de test aux motifs exclude par défaut de la couverture. Voir coverage.exclude.

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.*']
• CLI : vitest --exclude "**/fichier_exclu"

Liste de motifs glob à exclure de vos fichiers de test.

WARNING

Cette option n'affecte pas la couverture. Si vous devez supprimer certains fichiers du rapport de couverture, utilisez coverage.exclude.

C'est la seule option qui ne remplace pas votre configuration si vous l'indiquez avec un drapeau CLI. Tous les motifs glob ajoutés via l'indicateur --exclude seront ajoutés à la liste exclude de la configuration.

includeSource

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

Inclure les motifs glob pour les fichiers de test dans le code source.

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

server

• Type : { sourcemap?, deps?, ... }

Options du serveur Vite-Node.

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

Exporter le module transformé vers le système de fichiers. Si une chaîne est fournie, le module sera exporté vers le chemin spécifié.

server.debug.loadDumppedModules

• Type : boolean

Lire le module exporté à partir du système de fichiers à chaque fois qu'il existe. Utile pour le débogage en modifiant le résultat de l'exportation à partir du système de fichiers.

server.deps

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

Gestion de la résolution des dépendances.

server.deps.external

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

Définir une dépendance comme externe signifie que Vite transmettra le paquet directement à Node.js. Les dépendances externalisées ne seront pas soumises aux transformateurs et aux résolveurs de Vite, et ne prendront donc pas en charge HMR lors du rechargement. Par défaut, tous les paquets dans node_modules sont externalisés.

Ces options acceptent les noms de packages tels qu'ils apparaissent 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. Vitest vérifie toujours le chemin du fichier plutôt que le nom réel du package.

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

server.deps.inline

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

Vite traitera les modules inline. Cela peut être utile pour gérer les paquets qui livrent du .js au format ESM (que Node ne peut pas gérer).

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

server.deps.fallbackCJS

• Type boolean
• Par défaut : false

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

Cela pourrait potentiellement causer des incohérences si un paquet 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?, ... }

Gestion de la résolution des dépendances.

deps.optimizer

• Type : { ssr?, web? }
• 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.

Lorsque Vitest rencontre une bibliothèque externe répertoriée dans include, elle sera regroupée dans un seul fichier à l'aide d'esbuild et importée comme un module unique. C'est avantageux pour plusieurs raisons :

• L'importation de paquets avec beaucoup d'imports est coûteuse. En les regroupant dans un seul fichier, on peut 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 dans Node.js.
• Votre configuration alias est maintenant respectée à l'intérieur des paquets regroupés.
• Le code de vos tests s'exécute plus près de la façon dont il s'exécute dans le navigateur.

Notez que seuls les paquets 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 également de votre configuration optimizeDeps (pour le 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 votre code dans node_modules pour le débogage, car le code se trouve en fait dans votre répertoire cacheDir ou test.cache.dir. Si vous souhaitez déboguer avec des instructions console.log, modifiez-les directement ou forcez le regroupement avec l'option deps.optimizer?.[mode].force.

deps.optimizer.{mode}.enabled

• Type : boolean
• Par défaut : false

Activer l'optimisation des dépendances.

deps.web

• Type : { transformAssets?, ... }

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.

Habituellement, 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

Indique si Vitest doit traiter les fichiers d'assets (.png, .svg, .jpg, etc.) et les résoudre comme le fait Vite dans le navigateur.

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

WARNING

Pour le moment, cette option ne fonctionne qu'avec les pools vmThreads et vmForks.

deps.web.transformCss

• Type : boolean
• Par défaut : true

Indique si Vitest doit 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 l'option css, cette option masquera simplement les erreurs ERR_UNKNOWN_FILE_EXTENSION.

WARNING

Pour le moment, cette option ne fonctionne qu'avec les pools vmThreads et vmForks.

deps.web.transformGlobPattern

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

Modèle d'expression régulière pour faire correspondre les fichiers externes qui doivent être transformés.

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 asset, et que l'option correspondante n'est pas désactivée.

WARNING

Pour le moment, cette option ne fonctionne qu'avec les pools vmThreads et vmForks.

deps.interopDefault

• Type : boolean
• Par défaut : true

Interpréter la valeur par défaut du module CJS comme des exportations nommées. Certaines dépendances regroupent uniquement les modules CJS et n'utilisent pas les exportations nommées que Node.js peut analyser statiquement lorsqu'un paquet 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 n'effectue 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 éviter ce problème et ne générera pas d'erreur, mais vous pouvez désactiver ce comportement manuellement si votre code n'est pas traité.

deps.moduleDirectories

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

Liste de répertoires qui doivent être traités comme des répertoires de modules. Cette option de configuration affecte le comportement de vi.mock : lorsqu'aucune fabrique 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 affectera également le traitement d'un fichier 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 remplacera la valeur par défaut. Si vous souhaitez toujours rechercher node_modules pour les paquets, 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 d'accès à un exécuteur de test personnalisé. Il s'agit d'une fonctionnalité avancée destinée aux runners 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 pour inclure les fichiers de test de benchmark.

benchmark.exclude

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

Motifs glob pour exclure les fichiers de test de benchmark.

benchmark.includeSource

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

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

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

benchmark.reporters

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

Rapporteur personnalisé pour la sortie. 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

Obsolète au profit de benchmark.outputJson.

benchmark.outputJson

• Type : string | undefined
• Par défaut : undefined

Chemin d'accès au fichier pour stocker le résultat du benchmark, qui peut être utilisé pour l'option --compare ultérieurement.

Par exemple :

# enregistrer le résultat de la branche principale
git checkout main
vitest bench --outputJson main.json

# changer de branche et comparer avec la branche principale
git checkout feature
vitest bench --compare main.json

benchmark.compare

• Type : string | undefined
• Par défaut : undefined

Chemin d'accès au fichier vers un résultat de benchmark précédent à comparer avec les exécutions actuelles.

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 à l'intérieur des tests. Ils seront fusionnés avec les alias de resolve.alias.

WARNING

Vitest utilise les primitives SSR de Vite pour exécuter les tests, ce qui présente certains pièges.

1. Les alias affectent uniquement les modules importés directement avec un mot-clé import par un module en ligne (tout le code source est en ligne par défaut).
2. Vitest ne prend pas en charge l'aliasing des appels require.
3. Si vous définissez un alias pour une dépendance externe (par exemple, react -> preact), vous pouvez définir un alias pour les paquets node_modules réels à la place pour que cela fonctionne pour les dépendances externalisées. Yarn et pnpm prennent en charge l'aliasing via le préfixe npm:.

globals

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

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

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

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

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

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

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

// vitest.config.ts
import { defineConfig } from 'vitest/config';
import AutoImport from 'unplugin-auto-import/vite';

export default defineConfig({
  plugins: [
    AutoImport({
      imports: ['vitest'],
      dts: true, // générer une définition TypeScript
    }),
  ],
});

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.

TIP

Vous pouvez également utiliser le Mode Navigateur pour exécuter des tests d'intégration ou unitaires dans le navigateur sans avoir à simuler l'environnement.

Vous pouvez spécifier un environnement différent pour un fichier de test en ajoutant un bloc de documentation @vitest-environment (ou docblock) 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();
});

Style 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 vous exécutez Vitest avec l'option --isolate=false, les tests seront exécutés dans l'ordre suivant : node, jsdom, happy-dom, edge-runtime, custom environments. Les tests partageant le même environnement sont regroupés et exécutés séquentiellement.

Depuis la version 0.23.0, vous pouvez également définir un environnement personnalisé. Lorsqu'un environnement non intégré est utilisé, Vitest essaie de charger le paquet vitest-environment-${name}. Ce paquet doit exporter un objet conforme à l'interface Environment :

import type { Environment } from 'vitest';

export default <Environment>{
  name: 'custom',
  transformMode: 'ssr',
  setup() {
    // custom setup
    return {
      teardown() {
        // called after all tests with this env have been run
      },
    };
  },
};

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

TIP

L'environnement jsdom expose la variable globale jsdom égale à l'instance actuelle de JSDOM. Si vous souhaitez que TypeScript la reconnaisse, vous pouvez ajouter vitest/jsdom à votre tsconfig.json lorsque vous utilisez cet environnement :

{
  "compilerOptions": {
    "types": ["vitest/jsdom"]
  }
}

environmentOptions

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

Ces options sont transmises à la méthode setup de l'environment actuel. Par défaut, vous ne pouvez configurer que les options JSDOM si vous l'utilisez comme environnement de test.

environmentMatchGlobs

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

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

Par 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' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]
• Default: []

Permet d'attribuer automatiquement un pool d'exécution aux tests en fonction de motifs glob. La première correspondance est utilisée.

Par 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 vous aviez activé `--pool=threads` pour eux,
      ['**/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 vous n'avez pas spécifié d'autres globs
      // ...
    ],
  },
});

update*

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

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

watch*

• Type: boolean
• Default: !process.env.CI
• 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.

dir

• Type : string
• CLI : --dir=<path>
• Valeur par défaut : identique à root

Répertoire de base à scanner pour les fichiers de test. Vous pouvez spécifier cette option pour accélérer la découverte des tests si votre racine couvre l'ensemble du projet.

reporters*

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

Définit les reporters personnalisés pour la sortie des résultats. Les reporters peuvent être une instance de Reporter, une chaîne de caractères pour sélectionner les reporters intégrés, ou un chemin vers une implémentation personnalisée (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.

pool*

• Type: 'threads' | 'forks' | 'vmThreads' | 'vmForks'
• Default: 'forks'
• CLI: --pool=threads

Définit le pool utilisé pour exécuter les tests.

threads*

Active le multi-threading en utilisant tinypool (un fork léger de Piscina). Lorsque vous utilisez les threads, vous ne pouvez pas utiliser les API relatives aux processus telles que process.chdir(). Certaines bibliothèques écrites dans des langages natifs, telles que Prisma, bcrypt et canvas, rencontrent des problèmes lors de l'exécution dans plusieurs threads et génèrent des erreurs de segmentation. Dans ces cas, il est conseillé d'utiliser le pool forks à la place.

forks*

Similaire au pool threads, mais utilise child_process au lieu de worker_threads via tinypool. La communication entre les tests et le processus principal est moins rapide qu'avec le pool threads. Les API liées aux processus telles que process.chdir() sont disponibles dans le pool forks.

vmThreads*

Exécute les tests en utilisant le contexte VM (dans un bac à sable) dans un pool threads.

Cela accélère 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 (https://github.com/nodejs/node/issues/33439) ; pour éviter cela, envisagez de modifier manuellement la valeur de poolOptions.vmThreads.memoryLimit.

WARNING

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

• Les globales dans les modules natifs, telles 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 bac à sable.

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.

vmForks*

Similaire au pool vmThreads, mais utilise child_process au lieu de worker_threads via tinypool. La communication entre les tests et le processus principal est moins rapide qu'avec le pool vmThreads. Les API liées aux processus telles que process.chdir() sont disponibles dans le pool vmForks. Veuillez noter que ce pool présente les mêmes inconvénients que ceux énumérés dans vmThreads.

poolOptions*

• Type: Record<'threads' | 'forks' | 'vmThreads' | 'vmForks', {}>
• Default: {}

poolOptions.threads

Options pour le pool threads.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      threads: {
        // Threads related options here
      },
    },
  },
});

poolOptions.threads.maxThreads*

• Type : number | string
• Par défaut : CPUs disponibles

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

poolOptions.threads.minThreads*

• Type : number | string
• Par défaut : CPUs disponibles

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

poolOptions.threads.singleThread

• Type: boolean
• Default: false

Désactive l'isolation des modules intégrée (votre code source ou le code en ligne intégré sera réévalué à chaque test), ce qui peut améliorer les performances des tests.

WARNING

Bien que cette option force les tests à s'exécuter l'un après l'autre, 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 pourrait entraîner divers problèmes si vous vous fiez à l'état global (ce que font généralement les frameworks frontend) ou si votre code dépend du fait que l'environnement soit défini séparément pour chaque test. Cependant, cela peut accélérer vos tests (jusqu'à 3 fois plus rapide) s'ils ne s'appuient pas nécessairement sur l'état global ou peuvent facilement contourner cela.

poolOptions.threads.useAtomics*

• Type: boolean
• Default: false

Utilise Atomics pour synchroniser les threads.

Cela peut améliorer les performances dans certains cas, mais peut provoquer une erreur de segmentation dans les anciennes versions de Node.

poolOptions.threads.isolate

• Type: boolean
• Default: true

Isole l'environnement pour chaque fichier de test.

poolOptions.threads.execArgv*

• Type: string[]
• Default: []

Transmet des arguments supplémentaires à node dans les threads. Voir Command-line API | Node.js pour plus d'informations.

WARNING

Soyez prudent lorsque vous utilisez cette option, car certaines options peuvent faire planter le worker, par exemple --prof, --title. Voir https://github.com/nodejs/node/issues/41103.

poolOptions.forks

Options pour le pool forks.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      forks: {
        // Forks related options here
      },
    },
  },
});

poolOptions.forks.maxForks*

• Type : number | string
• Par défaut : CPU disponibles

Nombre maximal ou pourcentage de forks.

poolOptions.forks.minForks*

• Type : number | string
• Par défaut : CPU disponibles

Nombre minimal ou pourcentage de forks.

poolOptions.forks.isolate

• Type: boolean
• Default: true

Isole l'environnement pour chaque fichier de test.

poolOptions.forks.singleFork

• Type: boolean
• Default: false

Désactive l'isolation des modules intégrée (votre code source ou le code en ligne intégré sera réévalué à chaque test), ce qui peut améliorer les performances des tests.

WARNING

Bien que cette option force les tests à s'exécuter l'un après l'autre, elle est différente de --runInBand de Jest. Vitest utilise des processus enfants 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 pourrait entraîner divers problèmes si vous vous fiez à l'état global (ce que font généralement les frameworks frontend) ou si votre code dépend du fait que l'environnement soit défini séparément pour chaque test. Cependant, cela peut accélérer vos tests (jusqu'à 3 fois plus rapide) s'ils ne s'appuient pas nécessairement sur l'état global ou peuvent facilement contourner cela.

poolOptions.forks.execArgv*

• Type: string[]
• Default: []

Transmet des arguments supplémentaires au processus node dans les processus enfants. Voir Command-line API | Node.js pour plus d'informations.

WARNING

Soyez prudent lorsque vous utilisez cette option, car certaines options peuvent faire planter le worker, par exemple --prof, --title. Voir https://github.com/nodejs/node/issues/41103.

poolOptions.vmThreads

Options pour le pool vmThreads.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      vmThreads: {
        // VM threads related options here
      },
    },
  },
});

poolOptions.vmThreads.maxThreads*

• Type : number | string
• Par défaut : UC disponibles

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

poolOptions.vmThreads.minThreads*

• Type : number | string
• Par défaut : UC disponibles

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

poolOptions.vmThreads.memoryLimit*

• Type: string | number
• Default: 1 / CPU Cores

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 au lieu d'utiliser la valeur par défaut.

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 transformer en une valeur entière :

• <= 1 - La valeur est supposée être un pourcentage de la mémoire système. Donc 0.5 définit la limite de mémoire du worker à la moitié de la mémoire système totale.

• \> 1 - Supposé être une valeur d'octet fixe. En raison de la règle précédente, si vous vouliez une valeur de 1 octet (je ne sais pas pourquoi), vous pourriez 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.

poolOptions.vmThreads.useAtomics*

• Type: boolean
• Default: false

Utilise Atomics pour synchroniser les threads.

Cela peut améliorer les performances dans certains cas, mais peut provoquer une erreur de segmentation dans les anciennes versions de Node.

poolOptions.vmThreads.execArgv*

• Type: string[]
• Default: []

Transmet des arguments supplémentaires au processus node dans le contexte VM. Voir Command-line API | Node.js pour plus d'informations.

WARNING

Soyez prudent lorsque vous utilisez cette option, car certaines options peuvent faire planter le worker, par exemple --prof, --title. Voir https://github.com/nodejs/node/issues/41103.

poolOptions.vmForks

Options pour le pool vmForks.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      vmForks: {
        // VM forks related options here
      },
    },
  },
});

poolOptions.vmForks.maxForks*

• Type: number | string
• Par défaut : CPU disponibles

Nombre maximum ou pourcentage de threads. Vous pouvez également utiliser la variable d'environnement VITEST_MAX_FORKS.

poolOptions.vmForks.minForks*

• Type: number | string
• Par défaut : CPU disponibles

Nombre minimum ou pourcentage de threads. Vous pouvez également utiliser la variable d'environnement VITEST_MIN_FORKS.

poolOptions.vmForks.memoryLimit*

• Type: string | number
• Default: 1 / CPU Cores

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 au lieu d'utiliser la valeur par défaut. La façon dont la valeur est calculée est décrite dans poolOptions.vmThreads.memoryLimit.

poolOptions.vmForks.execArgv*

• Type: string[]
• Default: []

Transmet des arguments supplémentaires au processus node dans le contexte VM. Voir Command-line API | Node.js pour plus d'informations.

WARNING

Soyez prudent lorsque vous utilisez cette option, car certaines options peuvent faire planter le worker, par exemple --prof, --title. Voir https://github.com/nodejs/node/issues/41103.

fileParallelism*

• Type: boolean
• Par défaut: true
• CLI: --no-file-parallelism, --fileParallelism=false

Indique si l'exécution des fichiers de test doit se faire en parallèle. Définir cette option sur false forcera les options maxWorkers et minWorkers à 1.

TIP

Cette option n'affecte pas les tests exécutés au sein d'un même fichier. Pour les exécuter en parallèle, utilisez l'option concurrent sur describe ou via une configuration.

maxWorkers*

• Type: number | string

Nombre maximum de workers pour exécuter les tests. poolOptions.{threads,vmThreads}.maxThreads/poolOptions.forks.maxForks a une priorité plus élevée.

minWorkers*

• Type: number | string

Nombre minimum ou pourcentage de workers pour exécuter les tests. poolOptions.{threads,vmThreads}.minThreads/poolOptions.forks.minForks a une priorité plus élevée.

testTimeout

• Type: number
• Default: 5_000 dans Node.js, 15_000 si browser.enabled est true
• CLI: --test-timeout=5000, --testTimeout=5000

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

hookTimeout

• Type: number
• Default: 10_000 dans Node.js, 30_000 si browser.enabled est true
• CLI: --hook-timeout=10000, --hookTimeout=10000

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

teardownTimeout*

• Type: number
• Par défaut: 10000
• CLI: --teardown-timeout=5000, --teardownTimeout=5000

Délai d'attente maximal pour la phase de démontage (teardown) lorsque Vitest s'arrête, en millisecondes.

silent*

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

Supprime la sortie console des tests.

setupFiles

• Type: string | string[]

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

INFO

La modification d'un fichier de configuration déclenchera automatiquement une nouvelle exécution de tous les tests.

Vous pouvez utiliser process.env.VITEST_POOL_ID (chaîne de caractères ressemblant à un entier) à l'intérieur pour distinguer les threads.

TIP

Notez que si vous exécutez --isolate=false, ce fichier de configuration (setup) 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 répéter les mêmes actions plus que nécessaire.

Par exemple, vous pouvez vous appuyer sur une variable globale :

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

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

// hooks are reset before each suite
afterEach(() => {
  cleanup();
});

globalThis.resetBeforeEachTest = true;

provide 2.1.0+

• Type: Partial<ProvidedContext>

Définissez les valeurs accessibles dans vos tests à l'aide de la méthode inject.

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    provide: {
      API_KEY: '123',
    },
  },
});

my.test.js

import { expect, inject, test } from 'vitest';

test('api key is defined', () => {
  expect(inject('API_KEY')).toBe('123');
});

WARNING

Les propriétés doivent être des chaînes de caractères et les valeurs doivent être sérialisables car cet objet sera transféré entre différents processus.

TIP

Si vous utilisez TypeScript, vous devrez augmenter le type ProvidedContext pour un accès sécurisé par type :

// vitest.shims.d.ts

declare module 'vitest' {
  export interface ProvidedContext {
    API_KEY: string;
  }
}

// mark this file as a module so augmentation works correctly
export {};

globalSetup

• Type: string | string[]

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

Un fichier de configuration globale (global setup) peut exporter des fonctions nommées setup et teardown ou une fonction default qui renvoie une fonction de démontage (teardown) (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

La configuration globale ne s'exécute que s'il y a au moins un test en cours d'exécution. Cela signifie que la configuration globale peut commencer à s'exécuter en mode veille après la modification du fichier de test (le fichier de test attendra la fin de la configuration globale avant de s'exécuter).

Faites attention que la configuration globale s'exécute dans une portée globale différente, de sorte que vos tests n'ont pas accès aux variables définies ici. Cependant, vous pouvez transmettre des données sérialisables aux tests via la méthode provide :

globalSetup.js

export default function setup({ provide }) {
  provide('wsPort', 3000);
}

globalSetup.ts

import type { GlobalSetupContext } from 'vitest/node';

export default function setup({ provide }: GlobalSetupContext) {
  provide('wsPort', 3000);
}

declare module 'vitest' {
  export interface ProvidedContext {
    wsPort: number;
  }
}

example.test.js

import { inject } from 'vitest';

inject('wsPort') === 3000;

forceRerunTriggers*

• Type: string[]
• Par défaut: ['**/package.json/**', '**/vitest.config.*/**', '**/vite.config.*/**']

Modèle Glob des chemins de fichiers qui déclencheront la réexécution de toute la suite de tests. Si utilisé avec l'argument --changed, toute la suite de tests sera exécutée 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 cannot rerun this test, if content of `dist/index.js` changes
  await execa('node', ['dist/index.js']);
});

TIP

Assurez-vous que vos fichiers ne sont pas exclus par server.watch.ignored.

coverage*

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

Vous pouvez fournir des options de couverture au CLI avec la notation pointée :

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

WARNING

Si vous utilisez des options de couverture avec la notation pointée, n'oubliez pas de spécifier --coverage.enabled. Ne fournissez pas une seule option --coverage dans ce cas.

coverage.provider

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

Utilisez provider pour sélectionner l'outil de collecte de la couverture de code.

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 de code. Peut être remplacé à l'aide de 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 inclus dans la couverture de code sous forme de modèles Glob.

coverage.extension

• Type: string | string[]
• Par défaut: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.tsx', '.jsx', '.vue', '.svelte', '.marko', '.astro']
• 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/**',
  '**/node_modules/**',
  '**/[.]**',
  'packages/*/test?(s)/**',
  '**/*.d.ts',
  '**/virtual:*',
  '**/__x00__*',
  '**/\x00*',
  'cypress/**',
  'test?(s)/**',
  'test?(-*).?(c|m)[jt]s?(x)',
  '**/*{.,-}{test,spec,bench,benchmark}?(-d).?(c|m)[jt]s?(x)',
  '**/__tests__/**',
  '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build,eslint,prettier}.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 exclus de la couverture de code sous forme de modèles Glob.

Cette option remplace toutes les options par défaut. Vous devez étendre les options par défaut lorsque vous ajoutez de nouveaux modèles à ignorer :

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

export default defineConfig({
  test: {
    coverage: {
      exclude: ['**/custom-pattern/**', ...coverageConfigDefaults.exclude],
    },
  },
});

REMARQUE

Vitest ajoute automatiquement les motifs include des fichiers de test à la valeur par défaut de coverage.exclude.

coverage.all

• Type: boolean
• Par défaut: true
• CLI: --coverage.all, --coverage.all=false

Indique s'il faut inclure tous les fichiers, même ceux qui ne sont pas testés, dans le rapport.

coverage.clean

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

Nettoie les résultats de la couverture de code 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

Nettoyer le rapport de couverture lors du réexécution en mode veille. Mettre sur false pour préserver les résultats de couverture de la précédente exécution en mode veille.

coverage.reportsDirectory

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

WARNING

Vitest supprimera ce répertoire avant d'exécuter les tests si coverage.clean est activé (valeur par défaut).

Répertoire dans lequel écrire le rapport de couverture de code.

Pour prévisualiser le rapport de couverture de code dans la sortie du rapporteur HTML, cette option doit être définie comme un sous-répertoire du répertoire du rapport HTML (par exemple, ./html/coverage).

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>

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

Le rapporteur peut être défini de trois manières différentes :

• Un seul rapporteur : { reporter: 'html' }
• Plusieurs rapporteurs sans options : { reporter: ['html', 'json'] }
• Un ou plusieurs rapporteurs avec des options de rapporteur :

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

Vous pouvez également transmettre des rapporteurs de couverture personnalisés. Voir Guide - Rapporteur de couverture personnalisé pour plus d'informations.

{
  reporter: [
    // Specify reporter using name of the NPM package
    '@vitest/custom-coverage-reporter',
    ['@vitest/custom-coverage-reporter', { someOption: true }],

    // Specify reporter using local path
    '/absolute/path/to/custom-reporter.cjs',
    ['/absolute/path/to/custom-reporter.cjs', { someOption: true }],
  ];
}

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
• CLI: --coverage.reportOnFailure, --coverage.reportOnFailure=false

Génère un rapport de couverture de code même lorsque 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 de code des fichiers en dehors de la root du projet.

coverage.excludeAfterRemap 2.1.0+

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

Appliquer à nouveau les exclusions après que la couverture a été remappée sur les sources originales. Ceci est utile lorsque vos fichiers source sont transpilés et peuvent contenir des cartes de source de fichiers non sources.

Utilisez cette option lorsque vous voyez des fichiers apparaître dans le rapport même s'ils correspondent à vos modèles coverage.exclude.

coverage.skipFull

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

Exclut les fichiers avec une couverture de 100 % des instructions, des branches et des fonctions.

coverage.thresholds

Options pour les seuils de couverture de code.

coverage.thresholds.lines

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

Seuil global pour les lignes. Consultez la documentation d'Istanbul pour plus d'informations.

coverage.thresholds.functions

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

Seuil global pour les fonctions. Consultez la documentation d'Istanbul pour plus d'informations.

coverage.thresholds.branches

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

Seuil global pour les branches. Consultez la documentation d'Istanbul pour plus d'informations.

coverage.thresholds.statements

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

Seuil global pour les instructions. Consultez la documentation d'Istanbul pour plus d'informations.

coverage.thresholds.perFile

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

Vérifie les seuils par fichier.

coverage.thresholds.autoUpdate

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

Met à jour toutes les valeurs de seuil lines, functions, branches et statements dans le fichier de configuration lorsque la couverture actuelle est supérieure aux seuils configurés. Cette option permet de maintenir les seuils lorsque la couverture est améliorée.

coverage.thresholds.100

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

Définit les seuils globaux à 100. Raccourci pour --coverage.thresholds.lines 100 --coverage.thresholds.functions 100 --coverage.thresholds.branches 100 --coverage.thresholds.statements 100.

coverage.thresholds[glob-pattern]

• Type: { statements?: number functions?: number branches?: number lines?: number }
• Par défaut: undefined
• Disponible pour les fournisseurs: 'v8' | 'istanbul'

Définit les seuils pour les fichiers correspondant au modèle Glob.

NOTE

Vitest compte tous les fichiers, y compris ceux couverts par des modèles glob, dans les seuils de couverture globaux. Ce comportement est différent de celui de Jest.

{
  coverage: {
    thresholds: {
      // Thresholds for all files
      functions: 95,
      branches: 70,

      // Thresholds for matching glob pattern
      'src/utils/**.ts': {
        statements: 95,
        functions: 90,
        branches: 85,
        lines: 80,
      },

      // Files matching this pattern will only have lines thresholds set.
      // Global thresholds are not inherited.
      '**/math.ts': {
        lines: 100,
      }
    }
  }
}

coverage.thresholds[glob-pattern].100 2.1.0+

• Type: boolean
• Default: false
• Available for providers: 'v8' | 'istanbul'

Définit les seuils à 100 pour les fichiers correspondant au modèle glob.

{
  coverage: {
    thresholds: {
      // Seuils pour tous les fichiers
      functions: 95,
      branches: 70,

      // Seuils pour les fichiers correspondant au modèle glob
      'src/utils/**.ts': { 100: true },
      '**/math.ts': { 100: true }
    }
  }
}

coverage.ignoreEmptyLines

• Type: boolean
• Par défaut: true (false en v1)
• Disponible pour les fournisseurs: 'v8'
• CLI: --coverage.ignoreEmptyLines=<boolean>

Ignore les lignes vides, les commentaires et le code non exécutable, comme les types Typescript.

Cette option ne fonctionne que si le compilateur utilisé élimine les commentaires et autres codes non exécutables du code transpilé. Par défaut, Vite utilise ESBuild qui supprime les commentaires et les types Typescript des fichiers .ts, .tsx et .jsx.

Si vous souhaitez également appliquer ESBuild à d'autres fichiers, définissez-les dans les options esbuild :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  esbuild: {
    // Transpile all files with ESBuild to remove comments from code coverage.
    // Required for `test.coverage.ignoreEmptyLines` to work:
    include: ['**/*.js', '**/*.jsx', '**/*.mjs', '**/*.ts', '**/*.tsx'],
  },
  test: {
    coverage: {
      provider: 'v8',
      ignoreEmptyLines: true,
    },
  },
});

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 la couverture de code. Consultez la 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'
• CLI: --coverage.watermarks.statements=50,80, --coverage.watermarks.branches=50,80

Niveaux repères pour les instructions, les lignes, les branches et les fonctions. Consultez la documentation d'Istanbul pour plus d'informations.

coverage.processingConcurrency

• Type: boolean
• Par défaut: Math.min(20, os.availableParallelism?.() ?? os.cpus().length)
• Disponible pour les fournisseurs: 'v8' | 'istanbul'
• CLI: --coverage.processingConcurrency=<number>

Limite de concurrence utilisée lors du traitement des résultats de la couverture de code.

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 de fournisseur de couverture de code personnalisé. Consultez 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 les noms complets correspondent au motif spécifié. Si cette propriété contient OnlyRunThis, seuls les tests contenant le mot OnlyRunThis dans leur nom seront exécuté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 : !process.env.CI
• CLI : --open, --open=false

Ouvre l’interface utilisateur de Vitest (WIP - Work In Progress)

api

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

Active un serveur API sur un port spécifié. Si la valeur est true, le port par défaut est 51204.

browser

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

Exécute les tests Vitest dans un navigateur. Par défaut, WebdriverIO est utilisé, mais vous pouvez configurer un autre provider 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 SemVer, veuillez donc é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 des tests dans un navigateur par défaut. Peut être remplacé par l’option poolMatchGlobs.

browser.name

• Type : string
• CLI : --browser=safari

Spécifie le navigateur à utiliser pour l'exécution des tests. Les options possibles varient selon le provider :

• webdriverio : firefox, chrome, edge, safari
• playwright : firefox, webkit, chromium
• personnalisé : toute chaîne qui sera transmise au provider

browser.headless

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

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

browser.isolate

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

Exécute chaque test dans un iframe séparé.

browser.testerHtmlPath

• Type : string
• Par défaut : @vitest/browser/tester.html
• Version : Depuis Vitest 2.1.4

Chemin vers le point d'entrée HTML. Peut être relatif à la racine du projet. Ce fichier sera traité avec le hook transformIndexHtml.

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. Par défaut, Vitest attribue le port 63315 pour éviter les conflits avec le serveur de développement, ce qui vous permet d'exécuter les deux en parallèle.

browser.provider

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

Chemin vers un fournisseur qui sera utilisé lors de l'exécution des tests de navigateur. Vitest propose trois fournisseurs qui sont preview (par défaut), webdriverio et playwright. Les fournisseurs personnalisés doivent être exportés à l'aide de l'exportation default et avoir cette forme :

export interface BrowserProvider {
  name: string;
  getSupportedBrowsers: () => readonly string[];
  initialize: (
    ctx: Vitest,
    options: { browser: string; options?: BrowserProviderOptions }
  ) => Awaitable<void>;
  openPage: (url: string) => Awaitable<void>;
  close: () => Awaitable<void>;
}

WARNING

Il s'agit d'une API avancée pour les auteurs de bibliothèques. Si vous avez juste besoin d'exécuter des tests dans un navigateur, utilisez l'option browser.

browser.providerOptions

• Type : BrowserProviderOptions

Options qui seront transmises au provider lors de l’appel de provider.initialize.

export default defineConfig({
  test: {
    browser: {
      providerOptions: {
        launch: {
          devtools: true,
        },
      },
    },
  },
});

TIP

Pour une meilleure sécurité de type lors de l’utilisation de providers intégrés, vous pouvez ajouter l’un de ces types (pour le provider que vous utilisez) au champ compilerOptions.types de votre tsconfig :

{
  "compilerOptions": {
    "types": [
      "@vitest/browser/providers/webdriverio",
      "@vitest/browser/providers/playwright"
    ]
  }
}

browser.ui

• Type : boolean
• Par défaut : !isCI
• CLI : --browser.ui=false

Indique si l'interface utilisateur de Vitest doit être injectée dans la page. Par défaut, injecte l'iframe de l'interface utilisateur pendant le développement.

browser.viewport

• Type : { width, height }
• Par défaut : 414x896

Fenêtre d'affichage par défaut de l'iframe.

browser.locators

Options pour les localisateurs de navigateur intégrés.

browser.locators.testIdAttribute

• Type : string
• Par défaut : data-testid

Attribut utilisé pour trouver des éléments avec le localisateur getByTestId.

browser.screenshotDirectory

• Type : string
• Par défaut : __snapshots__ dans le répertoire du fichier de test

Chemin d'accès au répertoire des captures d'écran par rapport à la racine.

browser.screenshotFailures

• Type : boolean
• Par défaut : !browser.ui

Vitest doit-il prendre des captures d'écran si le test échoue ?

browser.orchestratorScripts

• Type : BrowserScript[]
• Par défaut : []

Scripts personnalisés qui doivent être injectés dans l'orchestrator HTML avant que les iframes de test ne soient lancées. Ce document HTML ne fait que configurer les iframes et n'importe pas réellement votre code.

Les scripts src et content seront traités par les plugins Vite. Le script doit être fourni sous la forme suivante :

export interface BrowserScript {
  /**
   * Si "content" est fourni et que le type est "module", ce sera son identifiant.
   *
   * Si vous utilisez TypeScript, vous pouvez ajouter l'extension `.ts` ici par exemple.
   * @default `injected-${index}.js`
   */
  id?: string;
  /**
   * Contenu JavaScript à injecter. Cette chaîne est traitée par les plugins Vite si le type est "module".
   *
   * Vous pouvez utiliser `id` pour donner à Vite un indice sur l'extension de fichier.
   */
  content?: string;
  /**
   * Chemin d'accès au script. Cette valeur est résolue par Vite, il peut donc s'agir d'un module node ou d'un chemin de fichier.
   */
  src?: string;
  /**
   * Indique si le script doit être chargé de manière asynchrone.
   */
  async?: boolean;
  /**
   * Type de script.
   * @default 'module'
   */
  type?: string;
}

browser.testerScripts

• Type : BrowserScript[]
• Par défaut : []

Scripts personnalisés à injecter dans le HTML du testeur avant l’initialisation de l’environnement de test. Ceci est utile pour injecter des polyfills requis pour l’implémentation du navigateur Vitest. Il est recommandé d’utiliser setupFiles dans la plupart des cas à la place.

Les scripts src et content seront traités par les plugins Vite.

browser.commands

• Type : Record<string, BrowserCommand>
• Par défaut : { readFile, writeFile, ... }

Commandes personnalisées qui peuvent être importées lors des tests du navigateur à partir de @vitest/browser/commands.

clearMocks

• Type : boolean
• Par défaut : false

Appelle .mockClear() sur tous les espions avant chaque test. Cela efface l’historique des mocks sans réinitialiser leur implémentation par défaut.

mockReset

• Type : boolean
• Par défaut : false

Appelle .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
• Par défaut : false

Appelle .mockRestore() sur tous les espions avant chaque test. Cela efface l’historique des mocks et réinitialise leur implémentation à celle d’origine.

unstubEnvs

• Type : boolean
• Par défaut : false

Appelle vi.unstubAllEnvs avant chaque test.

unstubGlobals

• Type : boolean
• Par défaut : false

Appelle vi.unstubAllGlobals avant chaque test.

testTransformMode

• Type : { web?, ssr? }

Définit comment transformer 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 exécutés dans un environnement JSDOM traiteront tous les fichiers avec l'indicateur ssr: false, tandis que les tests exécutés dans un environnement Node traiteront tous les modules avec ssr: true.

testTransformMode.ssr

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

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[]
• Par défaut : []

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.

TIP

Notez que le champ plugins de cet objet sera ignoré.

Si vous devez étendre le sérialiseur de snapshot via les plugins pretty-format, utilisez l’API expect.addSnapshotSerializer ou l’option snapshotSerializers.

snapshotSerializers*

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

Une liste de chemins vers les modules de sérialiseurs de snapshots pour les tests de snapshots. Utile si vous souhaitez ajouter des sérialiseurs de snapshots personnalisés. Voir Sérialiseur personnalisé pour plus d’informations.

resolveSnapshotPath*

• Type: (testPath: string, snapExtension: string) => string
• Par défaut: enregistre les snapshots dans le dossier __snapshots__

Remplace le chemin d’accès par défaut des snapshots. 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
• Par défaut: !process.env.CI
• CLI: --allowOnly, --allowOnly=false

Autorise l'exécution des tests et des suites marqués comme 'only'.

dangerouslyIgnoreUnhandledErrors*

• Type: boolean
• Par défaut: false
• CLI: --dangerouslyIgnoreUnhandledErrors --dangerouslyIgnoreUnhandledErrors=false

Ignore toutes les erreurs non gérées qui se produisent. Attention : à utiliser avec précaution.

passWithNoTests*

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

Indique à Vitest de ne pas signaler d'erreur si aucun test n'est trouvé.

logHeapUsage

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

Affiche l’utilisation de la mémoire après chaque test. Utile pour déboguer les fuites de mémoire.

css

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

Configure si le CSS doit être traité. S'il est exclu, les fichiers CSS seront remplacés par des chaînes vides pour éviter tout traitement ultérieur. Les modules CSS renverront un proxy afin de ne pas affecter l'exécution.

css.include

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

Modèle RegExp pour les fichiers qui doivent renvoyer du CSS valide et qui seront traités par le pipeline Vite.

TIP

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

css.exclude

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

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

css.modules

• Type: { classNameStrategy? }
• Par défaut: {}

css.modules.classNameStrategy

• Type: 'stable' | 'scoped' | 'non-scoped'
• Par défaut: 'stable'

Si vous choisissez de traiter les fichiers CSS, vous pouvez configurer si les noms de classe dans les CSS modules doivent être scopés. Vous pouvez choisir l’une des options suivantes :

• stable : les noms de classe seront générés comme _${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.generateScopedName si vous en avez une et que le traitement CSS est activé. Par défaut, le nom de fichier sera généré comme _${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 sur vos classes, vous devez activer le traitement CSS à l’aide de l’option include.

maxConcurrency

• Type: number
• Default: 5
• CLI: --max-concurrency=10, --maxConcurrency=10

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

Les tests dépassant cette limite seront placés en file d'attente et exécutés dès qu'un emplacement sera disponible.

cache*

• Type: false
• CLI: --no-cache, --cache=false

Utilisez cette option pour désactiver la fonctionnalité de cache. Vitest met en cache les résultats des tests afin de prioriser l'exécution des tests les plus longs et de ceux qui ont échoué.

Le répertoire de cache est contrôlé par l'option cacheDir de Vite :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  cacheDir: 'custom-folder/.vitest',
});

Vous pouvez limiter le répertoire uniquement pour Vitest en utilisant process.env.VITEST :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  cacheDir: process.env.VITEST ? 'custom-folder/.vitest' : undefined,
});

sequence

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

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

Vous pouvez spécifier les options de séquence via la CLI en utilisant la notation pointée :

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

sequence.sequencer*

• Type: TestSequencerConstructor
• Default: BaseSequencer

Une classe personnalisée définissant les méthodes de partitionnement et de tri des tests. Vous pouvez étendre BaseSequencer depuis vitest/node si vous n'avez besoin de redéfinir qu'une des méthodes sort et shard, mais les deux doivent être présentes.

Le partitionnement a lieu avant le tri, et uniquement si l'option --shard est spécifiée.

sequence.shuffle

• Type: boolean | { files?, tests? }
• Default: false
• CLI: --sequence.shuffle, --sequence.shuffle=false

Active l'exécution aléatoire des fichiers et des tests avec cette option, ou avec l'argument CLI --sequence.shuffle.

Vitest utilise généralement le cache pour trier les tests, ce qui accélère leur exécution en lançant les tests les plus longs en premier. L'exécution aléatoire des fichiers et des tests désactive cette optimisation, mais peut aider à identifier les tests qui dépendent involontairement d'une exécution précédente.

sequence.shuffle.files

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

Indique si les fichiers doivent être exécutés dans un ordre aléatoire. Notez que l'activation de cette option empêche la priorisation des tests de longue durée.

sequence.shuffle.tests

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

Indique si les tests doivent être exécutés dans un ordre aléatoire.

sequence.concurrent

• Type: boolean
• Default: false
• CLI: --sequence.concurrent, --sequence.concurrent=false

Active l'exécution parallèle des tests avec cette option, ou avec l'argument CLI --sequence.concurrent.

sequence.seed*

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

Définit la graine de randomisation pour l'exécution des tests 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 ordonne les hooks "after" dans l'ordre inverse de leur définition, et les hooks "before" dans l'ordre de leur définition.
• list ordonne tous les hooks dans l'ordre de leur définition.
• parallel exécute les hooks d'un même groupe en parallèle (les hooks des suites parentes s'exécutent toujours avant les hooks de la suite actuelle).

TIP

Cette option n'affecte pas onTestFinished. Cette fonction est toujours appelée dans l'ordre inverse.

sequence.setupFiles

• Type: 'list' | 'parallel'
• Default: 'parallel'
• CLI: --sequence.setupFiles=<value>

Modifie l'ordre d'exécution des fichiers de configuration (setup files).

• list exécute les fichiers de configuration dans l'ordre de leur définition.
• parallel exécute les fichiers de configuration en parallèle.

typecheck

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

typecheck.enabled

• Type: boolean
• Default: false
• CLI: --typecheck, --typecheck.enabled

Active la vérification de type en parallèle avec vos tests habituels.

typecheck.only

• Type: boolean
• Default: false
• CLI: --typecheck.only

Exécute uniquement les tests de vérification de type, lorsque la vérification de type est activée. L'utilisation de cette option via la CLI active automatiquement la vérification de type.

typecheck.checker

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

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

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

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

Vous pouvez également fournir 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 à traiter comme des fichiers de test de type.

typecheck.exclude

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

Modèle glob pour les fichiers à ne pas traiter comme des fichiers de test de type.

typecheck.allowJs

• Type: boolean
• Default: false

Vérifie les fichiers JS contenant le commentaire @ts-check. Si cette option est activée dans votre tsconfig, elle ne sera pas remplacée.

typecheck.ignoreSourceErrors

• Type: boolean
• Default: false

Empêche l'échec des tests si Vitest détecte 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: essaie de trouver le tsconfig.json le plus proche

Chemin vers un fichier tsconfig personnalisé, relatif à la racine du projet.

slowTestThreshold*

• Type: number
• Default: 300
• CLI: --slow-test-threshold=<number>, --slowTestThreshold=<number>

Le nombre de millisecondes après lequel un test ou une suite 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 }

Équivalent à la configuration de Chai.

chaiConfig.includeStack

• Type: boolean
• Default: false

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

chaiConfig.showDiff

• Type: boolean
• Default: true

Détermine si l'indicateur showDiff doit être inclus dans les erreurs d'assertion (AssertionErrors). false sera toujours false; true sera vrai lorsque l'assertion a demandé qu'une différence soit affichée.

chaiConfig.truncateThreshold

• Type: number
• Default: 40

Définit le seuil de longueur pour les valeurs réelles et attendues dans les erreurs 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 pour 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>

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

Par défaut, Vitest exécute tous les tests, même si certains échouent. Ce comportement 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 est détectée. L'option bail permet d'accélérer les builds CI en empêchant l'exécution de tests supplémentaires après la détection d'erreurs.

retry

• Type: number
• Default: 0
• CLI: --retry=<value>

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

onConsoleLog*

• Type: (log: string, type: 'stdout' | 'stderr') => boolean | 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 journaux des bibliothèques tierces.

import { defineConfig } from 'vitest/config';

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

onStackTrace*

• Type: (error: Error, frame: ParsedStack) => boolean | void

Applique une fonction de filtrage à chaque frame de chaque trace de pile lors de la gestion des erreurs. Le premier argument, error, est un objet avec les mêmes propriétés qu'un Error standard, mais ce n'est pas une instance réelle.

Peut être utile pour filtrer les frames de trace de pile des bibliothèques tierces.

import type { ParsedStack } from 'vitest';
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    onStackTrace(error: Error, { file }: ParsedStack): boolean | void {
      if (error.name === 'ReferenceError') return;
      if (file.includes('node_modules')) return false;
    },
  },
});

diff

• Type: string
• CLI: --diff=<value>

Chemin vers un fichier de configuration de diff qui sera utilisé pour générer l'interface de diff. Utile si vous souhaitez personnaliser l'affichage des diffs.

vitest.diff.ts

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

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

vitest.config.js

import { defineConfig } from 'vitest/config';

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

diff.truncateThreshold

• Type: number
• Default: 0

La longueur maximale du résultat de la différence à afficher. Les différences supérieures à ce seuil seront tronquées. La troncature est désactivée avec la valeur par défaut 0.

diff.truncateAnnotation

• Type: string
• Default: '... Diff result is truncated'

Annotation affichée à la fin du résultat de la différence si elle est tronquée.

diff.truncateAnnotationColor

• Type: DiffOptionsColor = (arg: string) => string
• Default: noColor = (string: string): string => string

Couleur de l'annotation de troncature. La valeur par défaut est affichée sans couleur.

fakeTimers

• Type: FakeTimerInstallOpts

Options que Vitest transmettra à @sinon/fake-timers lors de l'utilisation de vi.useFakeTimers().

fakeTimers.now

• Type: number | Date
• Default: Date.now()

Installe des faux timers avec l'époque Unix spécifiée.

fakeTimers.toFake

• Type: ('setTimeout' | 'clearTimeout' | 'setImmediate' | 'clearImmediate' | 'setInterval' | 'clearInterval' | 'Date' | 'nextTick' | 'hrtime' | 'requestAnimationFrame' | 'cancelAnimationFrame' | 'requestIdleCallback' | 'cancelIdleCallback' | 'performance' | 'queueMicrotask')[]
• Default: ['setTimeout', 'clearTimeout', 'setImmediate', 'clearImmediate', 'setInterval', 'clearInterval', 'Date']

Un tableau avec les noms des méthodes et des API globales à simuler ou à falsifier.

Pour simuler uniquement setTimeout() et nextTick(), spécifiez cette propriété comme ['setTimeout', 'nextTick'].

La simulation de nextTick n'est pas prise en charge lors de l'exécution de Vitest à l'intérieur de node:child_process en utilisant --pool=forks. NodeJS utilise process.nextTick en interne dans node:child_process et se bloque lorsqu'il est simulé. La simulation de nextTick est prise en charge lors de l'exécution de Vitest avec --pool=threads.

fakeTimers.loopLimit

• Type: number
• Default: 10_000

Le nombre maximal de timers qui seront exécutés lors de l'appel de vi.runAllTimers().

fakeTimers.shouldAdvanceTime

• Type: boolean
• Default: false

Indique à @sinonjs/fake-timers d'incrémenter automatiquement le temps simulé en fonction du décalage temporel réel du système (par exemple, le temps simulé est incrémenté de 20 ms pour chaque variation de 20 ms du temps réel).

fakeTimers.advanceTimeDelta

• Type: number
• Default: 20

Pertinent uniquement lors de l'utilisation avec shouldAdvanceTime: true. Incrémente le temps simulé de advanceTimeDelta ms pour chaque changement de advanceTimeDelta ms dans le temps réel du système.

fakeTimers.shouldClearNativeTimers

• Type: boolean
• Par défaut : true

Indique aux minuteurs factices de vider les minuteurs "natifs" (c'est-à-dire non factices) en déléguant à leurs gestionnaires respectifs. Lorsqu'elle est désactivée, cela peut entraîner un comportement potentiellement inattendu si des minuteurs existaient avant le début de la session des minuteurs factices.

workspace*

• Type: string
• CLI: --workspace=./file.js
• Default: vitest.{workspace,projects}.{js,ts,json} proche du fichier de configuration ou de la racine

Chemin vers un fichier de configuration d'espace de travail relatif à root.

isolate

• Type: boolean
• Default: true
• CLI: --no-isolate, --isolate=false

Exécute les tests dans un environnement isolé. Cette option n'a aucun effet sur les pools vmThreads et vmForks.

La désactivation de cette option peut améliorer les performances si votre code ne repose pas sur des effets secondaires (ce qui est généralement vrai pour les projets avec un environnement node).

TIP

Vous pouvez désactiver l'isolation pour des pools spécifiques en utilisant la propriété poolOptions.

includeTaskLocation

• Type: boolean
• Default: false

Indique si la propriété location doit être incluse lorsque l'API Vitest reçoit des tâches dans les rapporteurs. Si vous avez beaucoup de tests, cela pourrait entraîner une légère régression des performances.

La propriété location contient les valeurs column et line qui correspondent à la position de test ou describe dans le fichier d'origine.

Cette option sera automatiquement activée si vous ne la désactivez pas explicitement, et que vous exécutez Vitest avec :

• Vitest UI
• ou en utilisant le Mode Navigateur sans mode sans tête (headless)
• ou en utilisant le Rapporteur HTML

TIP

Cette option n'a aucun effet si vous n'utilisez pas de code personnalisé qui en dépend.

snapshotEnvironment

• Type: string

Chemin vers une implémentation d'environnement de snapshot personnalisé. Ceci est utile si vos tests sont exécutés dans un environnement qui ne prend pas en charge les API Node.js. Cette option n'a aucun effet sur un exécuteur de navigateur.

Cet objet doit avoir la forme de SnapshotEnvironment et est utilisé pour résoudre et lire/écrire des fichiers de snapshot :

export interface SnapshotEnvironment {
  getVersion: () => string;
  getHeader: () => string;
  resolvePath: (filepath: string) => Promise<string>;
  resolveRawPath: (testPath: string, rawPath: string) => Promise<string>;
  saveSnapshotFile: (filepath: string, snapshot: string) => Promise<void>;
  readSnapshotFile: (filepath: string) => Promise<string | null>;
  removeSnapshotFile: (filepath: string) => Promise<void>;
}

Vous pouvez étendre VitestSnapshotEnvironment par défaut à partir du module d'entrée vitest/snapshot si vous n'avez besoin d'écraser qu'une partie de l'API.

WARNING

Il s'agit d'une option de bas niveau et ne doit être utilisée que pour les cas avancés où vous n'avez pas accès aux API Node.js par défaut.

Si vous souhaitez simplement configurer la fonctionnalité de snapshots, utilisez les options snapshotFormat ou resolveSnapshotPath.

env

• Type : Partial<NodeJS.ProcessEnv>

Variables d'environnement disponibles sur process.env et import.meta.env lors des tests. Ces variables ne seront pas disponibles dans le processus principal (dans globalSetup, par exemple).

expect

• Type : ExpectOptions

expect.requireAssertions

• Type : boolean
• Par défaut : false

Équivalent à l'appel de expect.hasAssertions() au début de chaque test. Cela garantit qu'aucun test ne passera accidentellement.

TIP

Cela ne fonctionne qu'avec l'objet expect de Vitest. Si vous utilisez les assertions assert ou .should, elles ne seront pas comptées, et votre test échouera en raison du manque d'assertions expect.

Vous pouvez modifier cette valeur en appelant vi.setConfig({ expect: { requireAssertions: false } }). La configuration sera appliquée à chaque appel expect ultérieur jusqu'à ce que vi.resetConfig soit appelé manuellement.

expect.poll

Options de configuration globale pour expect.poll. Ce sont les mêmes options que vous pouvez transmettre à expect.poll(condition, options).

expect.poll.interval

• Type : number
• Par défaut : 50

Intervalle d'interrogation en millisecondes

expect.poll.timeout

• Type : number
• Par défaut : 1000

Délai d'interrogation en millisecondes

printConsoleTrace

• Type : boolean
• Par défaut : false

Imprimez toujours les traces de la console lors de l'appel de toute méthode console. Ceci est utile pour le débogage.