Configuration de Vitest

Si vous utilisez Vite et que vous disposez d'un fichier vite.config, Vitest le lira pour s'adapter aux plugins et à la configuration de votre application Vite. Si vous souhaitez une configuration différente pour les tests ou si votre application principale ne dépend pas spécifiquement de Vite, plusieurs options s'offrent à vous :

Créez un fichier vitest.config.ts. Ce fichier aura la priorité et remplacera la configuration de vite.config.ts (Vitest prend en charge toutes les extensions JS et TS conventionnelles, mais pas json). Cela signifie que toutes les options de votre vite.config seront ignorées.
Passez l'option --config à la CLI, par exemple vitest --config ./path/to/vitest.config.ts.
Utilisez process.env.VITEST ou la propriété mode sur defineConfig (qui sera définie sur test/benchmark si elle n'est pas remplacée par --mode) pour appliquer conditionnellement une configuration différente dans vite.config.ts.

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

Ouvrir les exemples de configuration

Lorsque vous utilisez defineConfig de vite, suivez ces instructions :

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

export default defineConfig({
  test: {
    // ... Spécifiez les options ici.
  },
});

La directive <reference types="vitest" /> ne fonctionnera plus dans Vitest 4, mais vous pouvez déjà commencer à migrer vers vitest/config :

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

export default defineConfig({
  test: {
    // ... Spécifiez les options ici.
  },
});

En utilisant defineConfig de vitest/config, vous devriez suivre ceci :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // ... Spécifiez les options ici.
  },
});

Vous pouvez récupérer 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 séparé, vous pouvez également étendre les options de Vite à partir d'un autre fichier de configuration si besoin :

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

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

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

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

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

WARNING

Toutes les options listées sur cette page se trouvent dans la propriété test de la configuration :

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

Étant donné que Vitest utilise la configuration Vite, 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. Ces options doivent être définies au niveau supérieur, pas dans une propriété test.

Les options de configuration non prises en charge dans une configuration de projet sont marquées par un signe *. Cela signifie qu'elles ne peuvent être définies que dans la configuration racine de Vitest.

include

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

Une liste de motifs glob qui correspondent à vos fichiers de test.

NOTE

Lors de l'utilisation de la couverture de code, 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,eslint,prettier}.config.*']
CLI : vitest --exclude "**/excluded-file"

Une liste de motifs glob qui doivent être exclus de vos fichiers de test.

WARNING

Cette option n'a pas d'impact sur la couverture de code. 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 la fournissez avec un argument CLI. Tous les motifs glob ajoutés via le drapeau --exclude seront ajoutés à l'exclude de la configuration.

includeSource

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

Inclut les motifs glob pour les fichiers de test in-source.

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

name

Type : string | { label: string, color?: LabelColor }

Attribue un nom personnalisé au projet de test ou au processus Vitest. Le nom sera visible dans la CLI et l'interface utilisateur, et disponible dans l'API Node.js via project.name.

La couleur utilisée par la CLI et l'interface utilisateur peut être modifiée en fournissant un objet avec la propriété color.

server

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

Options du serveur Vite-Node.

server.sourcemap

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

Injecte une source map intégrée aux modules.

server.debug

Type : { dumpModules?, loadDumppedModules? }

Options du débogueur Vite-Node.

server.debug.dumpModules

Type : boolean | string

Décharge le module transformé dans le système de fichiers. Passer une chaîne de caractères l'enregistrera dans le chemin spécifié.

server.debug.loadDumppedModules

Type : boolean

Lit le module déchargé du système de fichiers s'il existe. Utile pour le débogage en modifiant le résultat du vidage à 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\//]

Externaliser signifie que Vite transmettra le paquet directement à Node natif. Les dépendances externalisées ne seront pas traitées par les transformateurs et résolveurs de Vite, elles ne prennent donc pas en charge le HMR lors du rechargement. Par défaut, tous les paquets à l'intérieur de node_modules sont externalisés.

Ces options supportent les noms de paquets tels qu'ils sont écrits dans node_modules ou spécifiés dans deps.moduleDirectories. Par exemple, le paquet @company/some-name situé dans packages/some-name doit être spécifié comme some-name, et packages doit être inclus dans deps.moduleDirectories. En substance, Vitest vérifie toujours le chemin du fichier, pas le nom réel du paquet.

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

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 fournissent du .js au format ESM (que Node ne peut pas gérer).

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

server.deps.fallbackCJS

Type boolean
Par défaut : false

Lorsqu'une dépendance est un paquet ESM valide, Vitest essaiera 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 où 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

Active l'optimisation des dépendances. Si vous avez beaucoup de tests, cela pourrait améliorer leurs performances.

Lorsque Vitest rencontre la bibliothèque externe listée dans include, elle sera regroupée en un seul fichier à l'aide d'esbuild et importée en tant que module complet. C'est bon pour plusieurs raisons :

L'importation de paquets avec de nombreuses importations est coûteuse. En les regroupant en un seul fichier, cela permet de gagner beaucoup de temps.
L'importation de bibliothèques d'interface utilisateur est coûteuse car elles ne sont pas conçues pour être exécutées dans Node.js.
Votre configuration alias est maintenant prise en compte dans les paquets regroupés.
Le code de vos tests s'exécute de manière plus similaire à son exécution dans le navigateur.

Sachez que seuls les paquets de l'option deps.optimizer?.[mode].include sont regroupés (certains plugins les renseignent automatiquement, comme Svelte). Vous pouvez en savoir plus sur les options disponibles dans la documentation de 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 c'est configurable 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, cela étendra votre optimizeDeps lors de l'exécution des tests. Vitest supprime automatiquement les options de include si elles sont également listées dans exclude.

TIP

Vous ne pourrez pas modifier votre code node_modules à des fins de débogage, car le code est en fait situé 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 : false

Active 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, de sorte que ces options n'affecteront pas 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

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

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

WARNING

Actuellement, cette option ne fonctionne qu'avec les pools vmThreads et vmForks.

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 Vite le fait dans le navigateur.

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

WARNING

Actuellement, cette option ne fonctionne qu'avec les pools vmThreads et vmForks.

deps.web.transformGlobPattern

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

Motif RegExp pour identifier 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

Actuellement, cette option ne fonctionne qu'avec les pools vmThreads et vmForks.

deps.interopDefault

Type : boolean
Par défaut : true

Interprète l'exportation par défaut d'un module CJS comme des exportations nommées. Certaines dépendances ne contiennent que des modules CJS et n'utilisent pas d'exportations nommées que Node.js peut analyser statiquement lorsqu'un paquet est importé en utilisant la syntaxe import au lieu de require. Lors de l'importation de telles dépendances dans un environnement Node en utilisant des 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 contourner cela et n'échouera pas, mais vous pouvez désactiver ce comportement manuellement si votre code n'est pas traité.

deps.moduleDirectories

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

Une liste de répertoires qui seront considérés comme des répertoires de modules. Cette option de configuration affecte le comportement de vi.mock : lorsqu'aucune fonction de fabrique n'est fournie et que le chemin de l'élément que vous moquez correspond à l'une des valeurs de moduleDirectories, Vitest essaiera de résoudre le mock en recherchant un dossier __mocks__ à la racine du projet.

Cette option déterminera également si un fichier doit être traité comme un module lors de l'externalisation des dépendances. Par défaut, Vitest importe les modules externes en utilisant Node.js natif, contournant ainsi l'étape de transformation de Vite.

La définition de cette option remplacera la valeur par défaut. Si vous souhaitez toujours rechercher des paquets 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 runner de tests personnalisé. Il s'agit d'une fonctionnalité avancée qui doit être utilisée avec des runners de bibliothèques personnalisés. Vous pouvez en savoir plus à ce sujet dans la documentation.

benchmark

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

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

benchmark.include

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

Motifs glob à inclure pour les fichiers de test de benchmark.

benchmark.exclude

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

Motifs glob à exclure pour les fichiers de test de benchmark.

benchmark.includeSource

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

Inclure les motifs glob pour les fichiers de test de benchmark in-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 l'affichage des résultats. Peut contenir un ou plusieurs noms de rapporteurs intégrés, des instances de rapporteurs et/ou des chemins vers des rapporteurs personnalisés.

benchmark.outputFile

Obsolète, remplacé par benchmark.outputJson.

benchmark.outputJson

Type : string | undefined
Par défaut : undefined

Le chemin d'un fichier pour stocker le résultat du benchmark, qui peut être utilisé ultérieurement pour l'option --compare.

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 principale
git checkout feature
vitest bench --compare main.json

benchmark.compare

Type : string | undefined
Par défaut : undefined

Le chemin d'un 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 }>

Permet de définir des alias personnalisés lors de l'exécution des tests. Ils seront combiné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.

Les alias n'affectent que les modules importés directement avec un mot-clé import par un module inline (tout le code source est inline par défaut).
Vitest ne supporte pas l'aliasing des appels require.
Si vous aliassez une dépendance externe (par exemple, react -> preact), il peut être préférable d'aliaser les paquets node_modules réels afin que cela fonctionne pour les dépendances externalisées. Yarn et pnpm supportent 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 par souci d'explicité. Si vous préférez utiliser les API globalement comme Jest, vous pouvez utiliser l'option --globals en ligne de commande ou ajouter globals: true dans la configuration.

import { defineConfig } from 'vitest/config';

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

Pour permettre à TypeScript de fonctionner avec les API globales, ajoutez vitest/globals au champ types de votre tsconfig.json.

json

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

Si vous avez redéfini vos typeRoots pour inclure plus de types dans votre compilation, vous devrez réinclure les node_modules pour que vitest/globals soit découvrable.

json

{
  "compilerOptions": {
    "typeRoots": ["./types", "./node_modules/@types", "./node_modules"],
    "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.

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

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

environment

Type : 'node' | 'jsdom' | 'happy-dom' | 'edge-runtime' | string
Par défaut : 'node'
CLI : --environment=<env>

L'environnement utilisé pour les tests. L'environnement par défaut dans Vitest est l'environnement Node.js. Si vous construisez une application web, vous pouvez utiliser un environnement similaire à un navigateur, tel que jsdom ou happy-dom. Si vous construisez des fonctions edge, vous pouvez utiliser l'environnement edge-runtime.

TIP

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

En ajoutant un docblock ou un commentaire @vitest-environment au début du fichier, vous pouvez spécifier un autre environnement à utiliser pour tous les tests de ce fichier :

Style Docblock :

/**
 * @vitest-environment jsdom
 */

test('utiliser jsdom dans ce fichier de test', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Style de commentaire :

// @vitest-environment happy-dom

test('utiliser happy-dom dans ce fichier de test', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Pour la compatibilité avec Jest, il existe également un @jest-environment :

/**
 * @jest-environment jsdom
 */

test('utiliser jsdom dans ce fichier de test', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Si vous exécutez Vitest avec l'option --isolate=false, vos tests seront exécutés dans cet ordre : node, jsdom, happy-dom, edge-runtime, environnements personnalisés. Cela signifie que chaque test avec le même environnement est regroupé, mais s'exécute toujours séquentiellement.

À partir de la version 0.23.0, vous pouvez également définir un environnement personnalisé. Lorsqu'un environnement personnalisé est utilisé, Vitest essaiera de charger le paquet vitest-environment-${name}. Ce paquet doit exporter un objet qui respecte l'interface Environment :

import type { Environment } from 'vitest';

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

Vitest expose également builtinEnvironments via l'entrée vitest/environments, si vous souhaitez simplement l'étendre. Vous pouvez en savoir plus sur l'extension des environnements dans notre guide.

TIP

L'environnement jsdom expose la variable globale jsdom qui correspond à l'instance JSDOM actuelle. Si vous voulez que TypeScript la prenne en compte, vous pouvez ajouter vitest/jsdom à votre tsconfig.json lorsque vous utilisez cet environnement :

json

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

environmentOptions

Type : Record<'jsdom' | string, unknown>
Par défaut : {}

Ces options sont passées à la méthode setup de l'environment actuel. Par défaut, vous ne pouvez configurer que les options JSDOM, si vous l'employez en tant qu'environnement de test.

environmentMatchGlobs

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

DÉPRÉCIÉ

Cette API a été dépréciée dans Vitest 3. Utilisez les projets pour définir différentes configurations à la place.

export default defineConfig({
  test: {
    environmentMatchGlobs: [ 
      ['./*.jsdom.test.ts', 'jsdom'], 
    ], 
    projects: [ 
      { 
        extends: true, 
        test: { 
          environment: 'jsdom', 
        }, 
      }, 
    ], 
  },
})

L'environnement est automatiquement attribué en fonction des motifs glob. La première correspondance trouvée sera 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/ dont le nom se termine par .edge.test.ts s'exécuteront dans edge-runtime
      ['**/*.edge.test.ts', 'edge-runtime'],
      // ...
    ],
  },
});

poolMatchGlobs

Type : [string, 'threads' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]
Par défaut : []

DÉPRÉCIÉ

Cette API a été dépréciée dans Vitest 3. Utilisez les projets pour définir différentes configurations à la place :

export default defineConfig({
  test: {
    poolMatchGlobs: [ 
      ['./*.threads.test.ts', 'threads'], 
    ], 
    projects: [ 
      { 
        test: { 
          extends: true, 
          pool: 'threads', 
        }, 
      }, 
    ], 
  },
})

Le pool dans lequel les tests s'exécuteront est automatiquement attribué en fonction des motifs glob. La première correspondance sera utilisée.

Par exemple :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolMatchGlobs: [
      // tous les tests dans le répertoire "worker-specific" s'exécuteront dans un worker comme si vous aviez activé `--pool=threads` pour eux,
      ['**/tests/worker-specific/**', 'threads'],
      // tous les tests dans le répertoire "browser" seront exécutés dans un navigateur réel
      ['**/tests/browser/**', 'browser'],
      // tous les autres tests s'exécuteront en fonction des options "browser.enabled" et "threads", à moins que vous n'ayez spécifié d'autres motifs glob
      // ...
    ],
  },
});

update*

Type : boolean
Par défaut : 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
Par défaut : !process.env.CI && process.stdin.isTTY
CLI : -w, --watch, --watch=false

Active le mode de surveillance.

Dans les environnements interactifs, ce mode est activé par défaut, sauf si --run est spécifié explicitement.

En CI, ou lors de l'exécution à partir d'un shell non interactif, le mode "watch" n'est pas activé par défaut, mais peut être activé explicitement avec ce drapeau.

watchTriggerPatterns 3.2.0+ *

Type : WatcherTriggerPattern[]

Vitest réexécute les tests en fonction du graphe de modules qui est construit à partir des instructions import statiques et dynamiques. Cependant, si vous lisez à partir du système de fichiers ou que vous effectuez des requêtes via un proxy, Vitest ne peut pas détecter ces dépendances.

Pour réexécuter correctement ces tests, vous pouvez définir un motif d'expression régulière et une fonction qui renvoie une liste de fichiers de test à exécuter.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    watchTriggerPatterns: [
      {
        pattern: /^src\/(mailers|templates)\/(.*)\.(ts|html|txt)$/,
        testToRun: (id, match) => {
          // relatif à la valeur racine
          return `./api/tests/mailers/${match[2]}.test.ts`;
        },
      },
    ],
  },
});

WARNING

Les fichiers renvoyés doivent être absolus ou relatifs à la racine. Notez qu'il s'agit d'une option globale et qu'elle ne peut pas être utilisée au sein des configurations de projet.

root

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

Racine du projet.

dir

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

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

reporters*

Type : Reporter | Reporter[]
Par défaut : 'default'
CLI : --reporter=<name>, --reporter=<name1> --reporter=<name2>

Rapporteurs personnalisés pour l'affichage des résultats. Les rapporteurs peuvent être une instance de Reporter, une chaîne de caractères désignant des rapporteurs 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

Permet d'écrire 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 de caractères, vous pouvez spécifier des fichiers de sortie individuels lorsque vous utilisez plusieurs rapporteurs.

pool*

Type : 'threads' | 'forks' | 'vmThreads' | 'vmForks'
Par défaut : 'forks'
CLI : --pool=threads

Le pool utilisé pour l'exécution des tests.

threads*

Active le multithreading à l'aide de tinypool (une version allégée de Piscina). Lorsque vous utilisez des threads, il n'est pas possible d'utiliser les API liées aux processus telles que process.chdir(). Certaines bibliothèques écrites dans des langages natifs, telles que Prisma, bcrypt et canvas, posent des problèmes lors de l'exécution dans plusieurs threads et rencontrent des erreurs de segmentation. Dans ces cas, il est recommandé 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 relatives aux processus telles que process.chdir() sont disponibles dans le pool forks.

vmThreads*

Exécute les tests en utilisant le contexte VM (dans un environnement isolé) dans un pool de 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 auront des fuites de mémoire - pour y remédier, envisagez de modifier manuellement la valeur de poolOptions.vmThreads.memoryLimit.

WARNING

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

Les variables globales au sein des 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 utilisera 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 de manière illimitée, ce qui introduit des fuites de mémoire si vous avez beaucoup de contextes (fichiers de test). Il n'y a pas d'API dans Node.js permettant d'effacer ce cache.
L'accès aux globales est plus lent dans un environnement sandbox.

Veuillez prendre note de ces problèmes lorsque vous utilisez cette option. L'équipe Vitest ne peut pas résoudre ces problèmes par nous-mê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 relatives aux processus telles que process.chdir() sont disponibles dans le pool vmForks. Il est important de noter que ce pool présente les mêmes pièges que ceux listés dans vmThreads.

poolOptions*

Type : Record<'threads' | 'forks' | 'vmThreads' | 'vmForks', {}>
Par défaut : {}

poolOptions.threads

Options pour le pool threads.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      threads: {
        // Options liées aux threads ici
      },
    },
  },
});

poolOptions.threads.maxThreads*

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

Nombre maximal ou pourcentage de threads. Vous pouvez également spécifier la variable d'environnement VITEST_MAX_THREADS.

poolOptions.threads.minThreads*

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

Nombre minimal ou pourcentage de threads. Vous pouvez également spécifier la variable d'environnement VITEST_MIN_THREADS.

poolOptions.threads.singleThread

Type : boolean
Par défaut : false

Permet d'exécuter tous les tests avec le même environnement dans un seul thread de travail. Cela désactivera l'isolation de module native (votre code source ou le code inline sera toujours réévalué pour chaque test), mais cela peut améliorer les performances des tests.

WARNING

Même si cette option obligera les tests à s'exécuter séquentiellement, cette option est différente de --runInBand de Jest. Vitest utilise des workers tant pour exécuter les tests en parallèle que pour fournir une isolation. En désactivant cette option, vos tests s'exécuteront séquentiellement, mais dans le même contexte global, il vous incombe donc d'assurer l'isolation vous-même.

Cela pourrait causer divers problèmes si vous dépendez de l'état global (ce que font généralement les frameworks frontend) ou si votre code dépend de l'environnement pour être défini séparément pour chaque test. Mais cela peut accélérer vos tests (jusqu'à 3 fois plus rapide) s'ils ne dépendent pas nécessairement de l'état global ou peuvent facilement le contourner.

poolOptions.threads.useAtomics*

Type : boolean
Par défaut : false

Permet d'utiliser les Atomics pour synchroniser les threads.

Cela peut améliorer les performances dans certains cas, mais peut entraîner un segfault dans les anciennes versions de Node.

poolOptions.threads.isolate

Type: boolean
Default: true

Isoler l'environnement pour chaque fichier de test.

poolOptions.threads.execArgv*

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

Permet de passer des arguments supplémentaires à node dans les threads. Voir API de ligne de commande | Node.js pour plus d'informations.

WARNING

Soyez prudent lors de l'utilisation, 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: {
        // Options liées aux forks ici
      },
    },
  },
});

poolOptions.forks.maxForks*

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

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

poolOptions.forks.minForks*

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

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

poolOptions.forks.isolate

Type : boolean
Par défaut : true

Permet d'isoler l'environnement pour chaque fichier de test.

poolOptions.forks.singleFork

Type : boolean
Par défaut : false

Permet d'exécuter tous les tests avec le même environnement dans un seul processus enfant. Cela désactivera l'isolation de module native (votre code source ou le code inline sera toujours réévalué pour chaque test), mais cela peut améliorer les performances des tests.

WARNING

Même si cette option obligera les tests à s'exécuter séquentiellement, cette option est différente de --runInBand de Jest. Vitest utilise des processus enfants tant pour exécuter les tests en parallèle que pour fournir une isolation. En désactivant cette option, vos tests s'exécuteront séquentiellement, mais dans le même contexte global, il vous incombe donc d'assurer l'isolation vous-même.

poolOptions.forks.execArgv*

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

Permet de passer des arguments supplémentaires au processus node dans les processus enfants. Voir API de ligne de commande | Node.js pour plus d'informations.

WARNING

Soyez prudent lors de l'utilisation, 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: {
        // Options liées aux threads VM ici
      },
    },
  },
});

poolOptions.vmThreads.maxThreads*

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

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

poolOptions.vmThreads.minThreads*

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

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

poolOptions.vmThreads.memoryLimit*

Type : string | number
Par défaut : 1 / CPU Cores

Définit 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 recommandé de la spécifier manuellement plutôt que de se fier à la valeur par défaut.

TIP

Cette implémentation s'appuie sur workerIdleMemoryLimit de Jest.

La limite peut être spécifiée de différentes manières. Le résultat est ensuite arrondi à l'entier inférieur (Math.floor) :

<= 1 - La valeur est supposée être un pourcentage de la mémoire système. Ainsi, 0.5 définit la limite de mémoire du worker à la moitié de la mémoire système totale.
> 1 - Est considéré comme une valeur fixe en octets. En raison de la règle précédente, si vous vouliez une valeur de 1 octet (bien que cela soit peu probable), 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 désigner une limite de mémoire fixe.
  - K / KB - Kilo-octets (x1000)
  - KiB - Kibioctets (x1024)
  - M / MB - Méga-octets - MiB - Mébioctets
  - G / GB - Giga-octets - GiB - Gibioctets

WARNING

La limite de mémoire basée sur le pourcentage ne fonctionne pas sur les workers Linux CircleCI à cause d'un rapport de mémoire système incorrect.

poolOptions.vmThreads.useAtomics*

Type : boolean
Par défaut : false

Permet d'utiliser les 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[]
Par défaut : []

Permet de passer des arguments supplémentaires au processus node dans le contexte VM. Voir API de ligne de commande | Node.js pour plus d'informations.

WARNING

Soyez prudent lors de l'utilisation, 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: {
        // Options liées aux forks VM ici
      },
    },
  },
});

poolOptions.vmForks.maxForks*

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

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

poolOptions.vmForks.minForks*

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

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

poolOptions.vmForks.memoryLimit*

Type : string | number
Par défaut : 1 / CPU Cores

Définit 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. Le calcul de cette valeur est décrit dans poolOptions.vmThreads.memoryLimit.

poolOptions.vmForks.execArgv*

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

Permet de passer des arguments supplémentaires au processus node dans le contexte VM. Voir API de ligne de commande | Node.js pour plus d'informations.

WARNING

Soyez prudent lors de l'utilisation, 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 tous les fichiers de test doivent s'exécuter en parallèle. Définir cette option sur false remplacera les options maxWorkers et minWorkers par 1.

TIP

Cette option n'a pas d'incidence sur les tests exécutés dans le même fichier. Si vous souhaitez les exécuter en parallèle, utilisez l'option concurrent avec describe ou via une configuration.

maxWorkers*

Type : number | string

Nombre maximal ou pourcentage de workers pour l'exécution des tests. poolOptions.{threads,vmThreads}.maxThreads/poolOptions.forks.maxForks est prioritaire.

minWorkers*

Type : number | string

Nombre minimal ou pourcentage de workers pour l'exécution des tests. poolOptions.{threads,vmThreads}.minThreads/poolOptions.forks.minForks est prioritaire.

testTimeout

Type : number
Par défaut : 5_000 en Node.js, 15_000 si browser.enabled est true
CLI : --test-timeout=5000, --testTimeout=5000

Le délai d'attente par défaut d'un test, en millisecondes. Définissez à 0 pour désactiver complètement le délai d'attente.

hookTimeout

Type : number
Par défaut : 10_000 en Node.js, 30_000 si browser.enabled est true
CLI : --hook-timeout=10000, --hookTimeout=10000

Le délai d'attente par défaut d'un hook, en millisecondes. Définissez à 0 pour désactiver complètement le délai d'attente.

teardownTimeout*

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

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

silent*

Type : boolean | 'passed-only'
Par défaut : false
CLI : --silent, --silent=false

Rend la sortie console des tests silencieuse.

Utilisez 'passed-only' pour ne voir les logs que des tests échoués. Les logs des tests échoués sont imprimés une fois le test terminé.

setupFiles

Type : string | string[]

Chemin vers les fichiers de setup. Ils s'exécuteront avant chaque fichier de test.

INFO

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

Vous pouvez utiliser process.env.VITEST_POOL_ID (chaîne de caractères de type entier) pour distinguer les threads.

TIP

Notez que si vous exécutez --isolate=false, ce fichier de 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, alors assurez-vous de ne pas faire la même chose inutilement.

Par exemple, vous pourriez dépendre d'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;

provide 2.1.0+

Type : Partial<ProvidedContext>

Permet de définir des valeurs qui peuvent être accédées dans vos tests en utilisant la méthode inject.

vitest.config.jsapi.test.js

import { defineConfig } from 'vitest/config';

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

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

test('la clé API est définie', () => {
  expect(inject('API_KEY')).toBe('123');
});

WARNING

Les propriétés doivent être des chaînes 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 typé :

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

// marquer ce fichier comme un module pour que l'augmentation fonctionne correctement
export {};

globalSetup

Type : string | string[]

Chemin vers les fichiers de global setup, relatif à la racine du projet.

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

INFO

Plusieurs fichiers globalSetup peuvent être utilisés. setup et teardown sont exécutés séquentiellement, les fonctions de teardown étant exécutées dans l'ordre inverse.

WARNING

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

Sachez que le global setup 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 passer des données sérialisables aux tests via la méthode provide :

example.test.jsglobalSetup.ts 3.0.0+ globalSetup.ts 2.0.0+

import { inject } from 'vitest';

inject('wsPort') === 3000;

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

export default function setup(project: TestProject) {
  project.provide('wsPort', 3000);
}

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

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

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

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

Depuis Vitest 3, vous pouvez définir une fonction de rappel personnalisée qui sera appelée lorsque Vitest réexécute les tests. Si la fonction est asynchrone, le runner attendra qu'elle se termine avant d'exécuter les tests. Notez que vous ne pouvez pas déstructurer l'objet project de la même manière que { onTestsRerun } car cela dépend du contexte.

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

export default function setup(project: TestProject) {
  project.onTestsRerun(async () => {
    await restartDb();
  });
}

forceRerunTriggers*

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

Motif glob pour les chemins de fichiers qui déclenchera la réexécution de toute la suite. Lorsqu'il est associé à l'argument --changed, cela exécutera toute la suite de tests si le déclencheur est trouvé dans le diff de git.

Utile si vous testez des appels de commandes CLI, car Vite ne peut pas construire un graphe de modules :

test('exécuter un script', async () => {
  // Vitest ne peut pas réexécuter ce test en cas de modification du contenu de `dist/index.js`
  await execa('node', ['dist/index.js']);
});

TIP

Assurez-vous que vos fichiers ne sont pas ignorés par server.watch.ignored.

coverage*

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

Vous pouvez spécifier des options de couverture en ligne de commande avec la notation par points :

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

WARNING

Si vous utilisez les options de couverture avec la notation par points, il est impératif de spécifier --coverage.enabled. Il ne faut pas fournir une seule option --coverage dans ce cas.

coverage.provider

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

Permet de sélectionner l'outil de collecte de 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 couverture. Peut être remplacé 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 inclus dans la couverture selon des motifs 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 selon des motifs glob.

Cette option annule toutes les options par défaut. Il est recommandé d'étendre les options par défaut lorsque vous ajoutez de nouveaux motifs à ignorer :

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

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

NOTE

Vitest ajoute automatiquement les motifs include des fichiers de test dans coverage.exclude. La couverture des fichiers de test ne peut pas être affichée.

coverage.all

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

Indique s'il faut inclure tous les fichiers, y compris ceux non testés, au 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 couverture avant l'exécution des tests.

coverage.cleanOnRerun

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

Nettoie le rapport de couverture lors d'une réexécution en mode surveillance. Définissez sur false pour conserver les résultats de couverture de l'exécution précédente en mode surveillance.

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 l'exécution des tests si coverage.clean est activé (valeur par défaut).

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

Pour prévisualiser le rapport de couverture 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>

Les rapporteurs de couverture à utiliser. Voir la documentation d'istanbul afin d'obtenir une liste détaillée de tous les rapporteurs. Voir @types/istanbul-reporter afin d'obtenir plus de détails sur les options spécifiques aux rapporteurs.

Le rapporteur se présente sous trois formes différentes :

Un rapporteur unique : { reporter: 'html' }
Plusieurs rapporteurs sans configuration d'options : { reporter: ['html', 'json'] }

Un ou plusieurs rapporteurs avec des options spécifiques au rapporteur :

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

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

{
  reporter: [
    // Spécifier le rapporteur en utilisant le nom du paquet NPM
    '@vitest/custom-coverage-reporter',
    ['@vitest/custom-coverage-reporter', { someOption: true }],

    // Spécifier le rapporteur en utilisant un chemin local
    '/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
Disponible pour les fournisseurs : 'v8' | 'istanbul'
CLI : --coverage.reportOnFailure, --coverage.reportOnFailure=false

Permet de générer 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

Permet de collecter la couverture des fichiers en dehors de la racine 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

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

Utilisez cette option lorsque des fichiers apparaissent dans le rapport même s'ils correspondent à vos motifs coverage.exclude.

coverage.skipFull

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

Permet de ne pas afficher les fichiers avec une couverture de 100 % des instructions, des branches et des fonctions.

coverage.thresholds

Options pour les seuils de couverture.

Si un seuil est défini sur un nombre positif, il sera interprété comme le pourcentage minimum de couverture requis. Par exemple, si le seuil de lignes est défini à 90, cela signifie que 90 % des lignes doivent être couvertes.

Si un seuil est défini sur un nombre négatif, il sera considéré comme le nombre maximal d'éléments non couverts autorisés. Par exemple, si le seuil de lignes est défini à -10, cela signifie qu'au maximum 10 lignes peuvent être non couvertes.

{
  coverage: {
    thresholds: {
      // Nécessite 90% de couverture de fonctions
      functions: 90,

      // Exige qu'au maximum 10 lignes ne soient pas couvertes
      lines: -10,
    }
  }
}

coverage.thresholds.lines

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

Définit le seuil global pour les lignes.

coverage.thresholds.functions

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

Définit le seuil global pour les fonctions.

coverage.thresholds.branches

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

Définit le seuil global pour les branches.

coverage.thresholds.statements

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

Définit le seuil global pour les instructions.

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 meilleure que les 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. C'est un 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 motif glob.

NOTE

Vitest compte tous les fichiers, y compris ceux couverts par des motifs glob, pour les seuils de couverture globaux. Cela diffère du comportement de Jest.

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

      // Seuils pour le motif glob correspondant
      'src/utils/**.ts': {
        statements: 95,
        functions: 90,
        branches: 85,
        lines: 80,
      },

      // Les fichiers correspondant à ce motif n'auront que les seuils de lignes appliqués.
      // Les seuils globaux ne sont pas pris en compte.
      '**/math.ts': {
        lines: 100,
      }
    }
  }
}

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

Type : boolean
Par défaut : false
Disponible pour les fournisseurs : 'v8' | 'istanbul'

Définit les seuils à 100 pour les fichiers correspondant au motif glob.

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

      // Seuils pour le motif glob correspondant
      '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 autres codes non exécutables, par exemple les types Typescript. Nécessite experimentalAstAwareRemapping: false.

Cette option n'est effective que si le compilateur utilisé supprime 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 appliquer ESBuild à d'autres fichiers également, ils doivent être définis dans les options esbuild :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  esbuild: {
    // Transpile tous les fichiers avec ESBuild afin de supprimer les commentaires de la couverture de code.
    // Requis pour que `test.coverage.ignoreEmptyLines` fonctionne :
    include: ['**/*.js', '**/*.jsx', '**/*.mjs', '**/*.ts', '**/*.tsx'],
  },
  test: {
    coverage: {
      provider: 'v8',
      ignoreEmptyLines: true,
    },
  },
});

coverage.experimentalAstAwareRemapping

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

Remappe la couverture avec une analyse expérimentale basée sur l'AST. Fournit des résultats plus précis comparativement au mode par défaut.

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

Filigranes pour les instructions, les lignes, les branches et les fonctions. Voir 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 appliquée lors du traitement des résultats de couverture.

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 du module 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>

Permet d'exécuter les tests dont les noms complets correspondent au motif. Si vous ajoutez OnlyRunThis à cette propriété, les tests qui ne contiennent pas le mot OnlyRunThis dans le nom du test seront ignorés.

import { expect, test } from 'vitest';

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

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

api

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

Permet d'écouter le port et de servir l'API. Lorsque cette option est définie sur true, le port par défaut est 51204.

browser expérimental

Par défaut : { enabled: false }
CLI : --browser=<name>, --browser.name=chrome --browser.headless

Configuration pour l'exécution des tests dans le navigateur. Veuillez consulter l'article "Référence de configuration du navigateur".

WARNING

Ceci est une fonctionnalité expérimentale. Les changements majeurs pourraient ne pas respecter SemVer ; il est recommandé d'épingler la version de Vitest lors de son utilisation.

clearMocks

Type : boolean
Par défaut : false

Appelle .mockClear() sur tous les espions avant chaque test. Cela réinitialisera l'historique des mocks sans affecter les implémentations des mocks.

mockReset

Type : boolean
Par défaut : false

Appelle .mockReset() sur tous les espions avant chaque test. Cela effacera l'historique des mocks et réinitialisera chaque implémentation à son original.

restoreMocks

Type : boolean
Par défaut : false

Appelle .mockRestore() sur tous les espions avant chaque test. Cela effacera l'historique des mocks, restaurera chaque implémentation à son état d'origine, et restaurera les descripteurs originaux des objets espionnés.

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étermine la méthode de transformation pour tous les modules importés dans un test qui correspond au motif glob. Par défaut, se base sur l'environnement. Par exemple, les tests avec l'environnement JSDOM traiteront tous les fichiers en utilisant l'option ssr: false et les tests avec l'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 des tests spécifiés.
Les plugins Vite recevront l'option 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 une réécriture SSR pour exécuter le code dans Node.
Les plugins Vite recevront l'option ssr: false lors du traitement de ces fichiers.

snapshotFormat*

Type : PrettyFormatOptions

Options de formatage pour les tests de snapshot. Ces options sont passées à pretty-format.

TIP

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

Si vous avez besoin d'étendre le sérialiseur de snapshot à l'aide de plugins pretty-format, veuillez utiliser l'API expect.addSnapshotSerializer ou l'option snapshotSerializers.

snapshotSerializers*

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

Une liste de chemins vers les modules de sérialisation de snapshot pour les tests de snapshot, qui est utile si vous souhaitez ajouter des sérialiseurs de snapshot personnalisés. Voir Sérialiseur personnalisé pour plus d'informations.

resolveSnapshotPath*

Type : (testPath: string, snapExtension: string, context: { config: SerializedConfig }) => string
Par défaut : stocke les fichiers de snapshot dans le répertoire __snapshots__

Remplace le chemin de snapshot par défaut. Par exemple, pour stocker les snapshots dans le même répertoire que les 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

Permet d'autoriser les tests et les suites marqués comme "only".

dangerouslyIgnoreUnhandledErrors*

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

Permet d'ignorer toutes les erreurs non gérées qui se produisent.

passWithNoTests*

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

Vitest n'échouera pas si aucun test n'est détecté.

logHeapUsage

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

Affiche l'utilisation de la mémoire après chaque test. Particulièrement utile pour déboguer les fuites de mémoire.

css

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

Permet de configurer si le CSS doit être traité. Lorsqu'il est exclu, les fichiers CSS seront remplacés par des chaînes vides pour contourner le 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 : []

Motif RegExp pour les fichiers qui devront renvoyer du CSS réel et qui seront traités par le pipeline Vite.

TIP

Pour traiter tous les fichiers CSS, il faut utiliser /.+/.

css.exclude

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

Motif RegExp pour les fichiers qui seront remplacés par 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 décidez de traiter les fichiers CSS, vous pouvez configurer si les noms de classe dans les modules CSS doivent avoir une portée limitée. Vous pouvez choisir l'une des options suivantes :

stable : les noms de classe seront générés sous la forme _${name}_${hashedFilename}, ce qui signifie que la classe générée restera la même si le contenu CSS est modifié, mais variera 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 fonction de snapshot.
scoped : les noms de classe seront générés comme d'habitude, en respectant la méthode css.modules.generateScopedName, si elle est définie 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 est basé sur 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, ce qui contourne le traitement des modules CSS. Si vous dépendez des propriétés CSS de vos classes, vous devez activer le traitement CSS à l'aide de l'option include.

maxConcurrency

Type : number
Par défaut : 5
CLI : --max-concurrency=10, --maxConcurrency=10

Le nombre de tests autorisés à s'exécuter simultanément, marqués avec test.concurrent.

Les tests dépassant cette limite seront mis en file d'attente pour s'exécuter dès qu'un emplacement sera disponible.

cache*

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

Cette option permet de désactiver la fonction de cache. Actuellement, Vitest met en cache les résultats de test afin d'exécuter les tests les plus longs et les tests échoués en premier.

Le répertoire de cache est défini par l'option cacheDir de Vite :

import { defineConfig } from 'vitest/config';

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

Vous pouvez restreindre le répertoire à Vitest uniquement 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?, groupOrder }

Options de tri des tests.

Vous pouvez fournir des options de séquence à la CLI avec la notation par points :

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

sequence.sequencer*

Type : TestSequencerConstructor
Par défaut : BaseSequencer

Une classe personnalisée qui définit des méthodes pour le partitionnement et le tri. Vous pouvez étendre BaseSequencer de vitest/node, si vous ne souhaitez redéfinir qu'une seule des méthodes sort et shard, mais les deux doivent exister.

Le partitionnement se produit avant le tri, et seulement si l'option --shard est fournie.

Si sequencer.groupOrder est spécifié, le séquenceur sera invoqué une fois par groupe et par pool.

groupOrder 3.2.0+

Type : number
Par défaut : 0

Contrôle l'ordre dans lequel ce projet exécute ses tests lors de l'utilisation de plusieurs projets.

Les projets ayant le même numéro d'ordre de groupe seront exécutés simultanément, et les groupes sont exécutés du plus bas au plus élevé.
Si vous ne définissez pas cette option, tous les projets seront exécutés en parallèle.
Si plusieurs projets utilisent le même ordre de groupe, ils seront exécutés simultanément.

Ce paramètre n'a d'incidence que sur l'ordre dans lequel les projets s'exécutent, pas l'ordre des tests au sein d'un projet. Pour contrôler l'isolation des tests ou l'ordre des tests au sein d'un projet, utilisez les options isolate et sequence.sequencer.

Exemple

Considérez cet exemple :

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    projects: [
      {
        test: {
          name: 'slow',
          sequence: {
            groupOrder: 0,
          },
        },
      },
      {
        test: {
          name: 'fast',
          sequence: {
            groupOrder: 0,
          },
        },
      },
      {
        test: {
          name: 'flaky',
          sequence: {
            groupOrder: 1,
          },
        },
      },
    ],
  },
});

Les tests de ces projets s'exécuteront dans cet ordre :

 0. slow  |
          |> exécution simultanée
 0. fast  |

 1. flaky |> s'exécute après slow et fast (seul)

sequence.shuffle

Type : boolean | { files?, tests? }
Par défaut : false
CLI : --sequence.shuffle, --sequence.shuffle=false

Si vous souhaitez que les fichiers et les tests s'exécutent de manière aléatoire, vous pouvez l'activer via cette option ou l'argument CLI --sequence.shuffle.

Vitest utilise généralement le cache pour trier les tests, de sorte que les tests de longue durée commencent plus tôt - cela rend les tests plus rapides. Si vos fichiers et tests s'exécutent dans un ordre aléatoire, vous perdrez cette amélioration des performances, mais cela peut être utile pour suivre les tests qui dépendent accidentellement d'un test exécuté précédemment.

sequence.shuffle.files

Type : boolean
Par défaut : false
CLI : --sequence.shuffle.files, --sequence.shuffle.files=false

Indique s'il faut randomiser les fichiers ; sachez que les tests de longue durée ne commenceront pas plus tôt si vous activez cette option.

sequence.shuffle.tests

Type : boolean
Par défaut : false
CLI : --sequence.shuffle.tests, --sequence.shuffle.tests=false

Permet de randomiser les tests.

sequence.concurrent

Type : boolean
Par défaut : false
CLI : --sequence.concurrent, --sequence.concurrent=false

Si vous souhaitez que les tests s'exécutent en parallèle, vous pouvez l'activer via cette option ou l'argument CLI --sequence.concurrent.

sequence.seed*

Type : number
Par défaut : Date.now()
CLI : --sequence.seed=1000

Définit la graine de randomisation si les tests s'exécutent dans un ordre aléatoire.

sequence.hooks

Type : 'stack' | 'list' | 'parallel'
Par défaut : 'stack'
CLI : --sequence.hooks=<value>

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

stack exécutera les hooks "after" dans l'ordre inverse, les hooks "before" s'exécuteront dans l'ordre où ils ont été définis.
list exécutera tous les hooks dans l'ordre où ils sont définis.
parallel exécutera les hooks au sein d'un même groupe en parallèle (les hooks des suites parentes s'exécuteront toujours avant les hooks de la suite actuelle).

TIP

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

sequence.setupFiles

Type : 'list' | 'parallel'
Par défaut : 'parallel'
CLI : --sequence.setupFiles=<value>

Modifie l'ordre d'exécution des fichiers de setup.

list exécutera les fichiers de setup dans l'ordre où ils sont définis.
parallel exécutera les fichiers de setup en parallèle.

typecheck

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

typecheck.enabled

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

Active la vérification de type en même temps que vos tests réguliers.

typecheck.only

Type : boolean
Par défaut : false
CLI : --typecheck.only

Exécute uniquement les tests de vérification de type lorsque la vérification de type est activée. Lorsque la CLI est utilisée, cette option activera automatiquement la vérification de type.

typecheck.checker

Type : 'tsc' | 'vue-tsc' | string
Par défaut : tsc

Les outils à utiliser pour la vérification de type. Vitest lancera un processus avec certains paramètres afin de faciliter l'analyse, selon le type. Le vérificateur devrait implémenter le même format de sortie que tsc.

Un paquet doit être installé pour utiliser le vérificateur de type :

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

Vous pouvez également spécifier 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[]
Par défaut : ['**/*.{test,spec}-d.?(c|m)[jt]s?(x)']

Motif glob pour les fichiers qui seront considérés comme des fichiers de test.

typecheck.exclude

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

Motif glob pour les fichiers qui ne seront pas considérés comme des fichiers de test.

typecheck.allowJs

Type : boolean
Par défaut : false

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

typecheck.ignoreSourceErrors

Type : boolean
Par défaut : false

Ne pas échouer si Vitest trouve des erreurs en dehors des fichiers de test. Cela ne vous montrera pas du tout les erreurs qui ne sont pas liées aux tests.

Par défaut, si Vitest détecte une erreur source, il fera échouer la suite de tests.

typecheck.tsconfig

Type : string
Par défaut : essaie de trouver le tsconfig.json le plus proche

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

typecheck.spawnTimeout

Type : number
Par défaut : 10_000

Temps minimum en millisecondes requis pour lancer le vérificateur de type.

slowTestThreshold*

Type : number
Par défaut : 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 rapporté comme tel dans les résultats.

chaiConfig

Type : { includeStack?, showDiff?, truncateThreshold? }
Par défaut : { includeStack: false, showDiff: true, truncateThreshold: 40 }

Équivalent à Chai config.

chaiConfig.includeStack

Type : boolean
Par défaut : false

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

chaiConfig.showDiff

Type : boolean
Par défaut : true

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

chaiConfig.truncateThreshold

Type : number
Par défaut : 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 dans le cas de grandes structures de données, la valeur est remplacée par quelque chose comme [ Array(3) ] ou { Object (prop1, prop2) }. Définir à 0 permet de désactiver complètement la troncature.

Cette option de configuration a une incidence sur la troncature des valeurs dans les titres test.each et dans le message d'erreur d'assertion.

bail

Type : number
Par défaut : 0
CLI : --bail=<value>

Arrête l'exécution des tests lorsque le nombre donné de tests a échoué.

Par défaut, Vitest exécutera tous vos scénarios de test même si certains d'entre eux échouent. Cela peut ne pas être souhaitable pour les builds CI où l'on ne s'intéresse qu'à des builds 100% réussis et où l'on souhaite arrêter l'exécution des tests le plus tôt possible en cas d'échec des tests. L'option bail peut être utilisée pour accélérer les exécutions CI en évitant l'exécution de plus de tests lorsque des échecs se sont produits.

retry

Type : number
Par défaut : 0
CLI : --retry=<value>

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

onConsoleLog*

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

Fonction de gestion personnalisée pour console.log dans les tests. Si vous renvoyez false, Vitest n'imprimera pas le log dans la console.

Peut être utile pour filtrer les messages de log 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'une Error standard, mais ce n'est pas une véritable instance.

Peut être utile pour filtrer les éléments de la 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 {
      // Si nous avons rencontré une ReferenceError, affichez toute la pile.
      if (error.name === 'ReferenceError') {
        return;
      }

      // Rejette toutes les frames des bibliothèques tierces.
      if (file.includes('node_modules')) {
        return false;
      }
    },
  },
});

diff

Type : string
CLI : --diff=<path>

Un objet DiffOptions ou un chemin vers un module qui exporte DiffOptions. Particulièrement utile si vous souhaitez personnaliser l'affichage des différences.

Par exemple, sous forme d'objet de configuration :

import { defineConfig } from 'vitest/config';
import c from 'picocolors';

export default defineConfig({
  test: {
    diff: {
      aIndicator: c.bold('--'),
      bIndicator: c.bold('++'),
      omitAnnotationLines: true,
    },
  },
});

Ou sous forme de module :

vitest.config.jsvitest.diff.ts

import { defineConfig } from 'vitest/config';

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

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

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

diff.expand

Type : boolean
Par défaut : true
CLI : --diff.expand=false

Développe toutes les lignes communes.

diff.truncateThreshold

Type : number
Par défaut : 0
CLI : --diff.truncateThreshold=<path>

La longueur maximale du résultat de la différence qui sera affiché. Les diffs dépassant ce seuil seront tronquées. La troncature n'aura aucun effet avec la valeur par défaut 0.

diff.truncateAnnotation

Type : string
Par défaut : '... Diff result is truncated'
CLI : --diff.truncateAnnotation=<annotation>

Annotation qui est affichée à la fin du diff si elle est tronquée.

diff.truncateAnnotationColor

Type : DiffOptionsColor = (arg: string) => string
Par défaut : noColor = (string: string): string => string

Couleur de l'annotation de troncature ; par défaut, elle est affichée sans couleur.

diff.printBasicPrototype

Type : boolean
Par défaut : false

Affiche le prototype de base Object et Array dans la sortie de la différence.

diff.maxDepth

Type : number
Par défaut : 20 (ou 8 lors de la comparaison de types différents)

Limite la profondeur de récursion lors de l'impression d'objets imbriqués.

fakeTimers

Type : FakeTimerInstallOpts

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

fakeTimers.now

Type : number | Date
Par défaut : Date.now()

Installe des faux minuteurs 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')[]
Par défaut : tout ce qui est disponible globalement sauf nextTick et queueMicrotask

Un tableau contenant les noms des méthodes et API globales à simuler.

Pour ne simuler que setTimeout() et nextTick(), cette propriété doit être spécifiée comme ['setTimeout', 'nextTick'].

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

fakeTimers.loopLimit

Type : number
Par défaut : 10_000

Le nombre maximal de minuteurs qui seront déclenchés lors de l'appel de vi.runAllTimers().

fakeTimers.shouldAdvanceTime

Type : boolean
Par défaut : false

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

fakeTimers.advanceTimeDelta

Type : number
Par défaut : 20

N'est pertinent que si utilisé avec shouldAdvanceTime: true. Incrémente le temps simulé de advanceTimeDelta ms toutes les advanceTimeDelta ms de changement dans le temps réel du système.

fakeTimers.shouldClearNativeTimers

Type : boolean
Par défaut : true

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

workspace*

DÉPRÉCIÉ

Cette option est obsolète et sera supprimée dans la prochaine version majeure. Il est recommandé d'utiliser projects à la place.

Type : string | TestProjectConfiguration[]
CLI : --workspace=./file.js
Par défaut : vitest.{workspace,projects}.{js,ts,json} près du fichier de configuration ou de la racine

Chemin vers un fichier de configuration de l'espace de travail relatif à la racine.

Depuis Vitest 3, vous pouvez également définir le tableau du workspace dans la configuration racine. Si le workspace est défini manuellement dans la configuration, Vitest ignorera le fichier vitest.workspace à la racine.

projects*

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

Un tableau de configurations de projets.

isolate

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

Exécute les tests dans un environnement isolé. Cette option n'affecte pas les pools vmThreads et vmForks.

Désactiver cette option peut améliorer les performances si votre code ne dépend pas d'effets secondaires (ce qui est généralement vrai pour les projets avec l'environnement node).

TIP

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

includeTaskLocation

Type : boolean
Par défaut : 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 peut entraîner une légère baisse de performance.

La propriété location contient les valeurs column et line qui correspondent à la position du test ou du describe dans le fichier original.

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 headless
ou en utilisant le Rapporteur HTML

TIP

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

snapshotEnvironment

Type : string

Le chemin vers une implémentation d'environnement de snapshot personnalisée. Ceci est utile si vous exécutez vos tests dans un environnement qui ne supporte pas les API Node.js. Cette option est sans effet sur un exécuteur de navigateur.

Cet objet doit respecter l'interface SnapshotEnvironment et est utilisé pour résoudre et lire/écrire les 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 point d'entrée vitest/snapshot si vous avez besoin de ne surcharger qu'une partie de l'API.

WARNING

Ceci est une option de niveau inférieur 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 avez juste besoin de configurer la fonctionnalité de snapshots, utilisez les options snapshotFormat ou resolveSnapshotPath.

env

Type : Partial<NodeJS.ProcessEnv>

Variables d'environnement accessibles via process.env et import.meta.env pendant les tests. Ces variables ne seront pas accessibles 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 réussira par inadvertance.

TIP

Cela n'est compatible qu'avec l'expect de Vitest. Si vous utilisez des assertions assert ou .should, elles ne seront pas prises en compte et votre test échouera en raison du manque d'assertions expect.

Vous pouvez modifier la valeur de ceci en appelant vi.setConfig({ expect: { requireAssertions: false } }). La configuration s'appliquera à chaque appel expect ultérieur jusqu'à ce que vi.resetConfig soit appelé manuellement.

expect.poll

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

expect.poll.interval

Type : number
Par défaut : 50

L'intervalle de sondage, en millisecondes.

expect.poll.timeout

Type : number
Par défaut : 1000

Le délai d'attente de sondage, en millisecondes.

printConsoleTrace

Type : boolean
Par défaut : false

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

attachmentsDir 3.2.0+

Type : string
Par défaut : '.vitest-attachments'

Le chemin du répertoire pour stocker les pièces jointes créées par context.annotate par rapport à la racine du projet.

Configuration de Vitest ​

include ​

exclude ​

includeSource ​

name ​

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.interopDefault ​

deps.moduleDirectories ​

runner ​

benchmark ​

benchmark.include ​

benchmark.exclude ​

benchmark.includeSource ​

benchmark.reporters ​

benchmark.outputFile ​

benchmark.outputJson ​

benchmark.compare ​

alias ​

globals ​

environment ​

environmentOptions ​

environmentMatchGlobs ​

poolMatchGlobs ​

update* ​

watch* ​

watchTriggerPatterns 3.2.0+ * ​

root ​

dir ​

reporters* ​

outputFile* ​

pool* ​

threads* ​

forks* ​

vmThreads* ​

vmForks* ​

poolOptions* ​

poolOptions.threads ​

poolOptions.threads.maxThreads* ​

poolOptions.threads.minThreads* ​

poolOptions.threads.singleThread ​

poolOptions.threads.useAtomics* ​

poolOptions.threads.isolate ​

poolOptions.threads.execArgv* ​

poolOptions.forks ​

poolOptions.forks.maxForks* ​

poolOptions.forks.minForks* ​

poolOptions.forks.isolate ​

poolOptions.forks.singleFork ​

poolOptions.forks.execArgv* ​

poolOptions.vmThreads ​

poolOptions.vmThreads.maxThreads* ​

poolOptions.vmThreads.minThreads* ​

poolOptions.vmThreads.memoryLimit* ​

poolOptions.vmThreads.useAtomics* ​

poolOptions.vmThreads.execArgv* ​

poolOptions.vmForks ​

poolOptions.vmForks.maxForks* ​

poolOptions.vmForks.minForks* ​

poolOptions.vmForks.memoryLimit* ​

poolOptions.vmForks.execArgv* ​

fileParallelism* ​

maxWorkers* ​

minWorkers* ​

testTimeout ​

Configuration de Vitest

include

exclude

includeSource

name

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

deps.moduleDirectories

runner

benchmark

benchmark.include

benchmark.exclude

benchmark.includeSource

benchmark.reporters

benchmark.outputFile

benchmark.outputJson

benchmark.compare

alias

globals

environment

environmentOptions

environmentMatchGlobs

poolMatchGlobs

update*

watch*

watchTriggerPatterns 3.2.0+ *

root

dir

reporters*

outputFile*

pool*

threads*

forks*

vmThreads*

vmForks*

poolOptions*

poolOptions.threads

poolOptions.threads.maxThreads*

poolOptions.threads.minThreads*

poolOptions.threads.singleThread

poolOptions.threads.useAtomics*

poolOptions.threads.isolate

poolOptions.threads.execArgv*

poolOptions.forks

poolOptions.forks.maxForks*

poolOptions.forks.minForks*

poolOptions.forks.isolate

poolOptions.forks.singleFork

poolOptions.forks.execArgv*

poolOptions.vmThreads

poolOptions.vmThreads.maxThreads*

poolOptions.vmThreads.minThreads*

poolOptions.vmThreads.memoryLimit*

poolOptions.vmThreads.useAtomics*

poolOptions.vmThreads.execArgv*

poolOptions.vmForks

poolOptions.vmForks.maxForks*

poolOptions.vmForks.minForks*

poolOptions.vmForks.memoryLimit*

poolOptions.vmForks.execArgv*

fileParallelism*

maxWorkers*

minWorkers*

testTimeout