Aller au contenu principal
Version : 29.7

Configuration de Jest

La philosophie de Jest est de fonctionner parfaitement par défaut, mais parfois vous avez besoin de plus de possibilités de configuration.

Il est recommandé de définir la configuration dans un fichier JavaScript dédié, TypeScript ou JSON. Le fichier sera détecté automatiquement, s'il est nommé jest.config.js|ts|mjs|cjs|json. Vous pouvez utiliser le drapeau --config pour passer un chemin explicite vers le fichier.

remarque

Gardez Ă  l'esprit que l'objet de configuration qui en rĂ©sulte doit toujours ĂȘtre sĂ©rialisable en JSON.

Le fichier de configuration devrait simplement exporter un objet :

/** @type {import('jest').Config} */
const config = {
verbose: true,
};

module.exports = config;

Ou une fonction renvoyant un objet :

/** @returns {Promise<import('jest').Config>} */
module.exports = async () => {
return {
verbose: true,
};
};
astuce

Pour lire les fichiers de configuration TypeScript, Jest nécessite ts-node. Assurez-vous qu'il soit installé dans votre projet.

La configuration peut Ă©galement ĂȘtre stockĂ©e dans un fichier JSON en tant qu'objet simple :

jest.config.json
{
"bail": 1,
"verbose": true
}

Alternativement la configuration de Jest peut ĂȘtre dĂ©finie via la clĂ© "jest" dans le package.json de votre projet :

package.json
{
"name": "my-project",
"jest": {
"verbose": true
}
}

Options​

info

Vous pouvez rĂ©cupĂ©rer les valeurs par dĂ©faut de Jest dans jest-config pour les Ă©tendre si nĂ©cessaire :

const {defaults} = require('jest-config');

/** @type {import('jest').Config} */
const config = {
moduleFileExtensions: [...defaults.moduleFileExtensions, 'mts', 'cts'],
};

module.exports = config;

RĂ©fĂ©rence​

automock [boolean]​

Par dĂ©faut : false

Cette option indique Ă  Jest que tous les modules importĂ©s dans vos tests doivent ĂȘtre simulĂ©s automatiquement. Tous les modules utilisĂ©s dans vos tests auront une implĂ©mentation de remplacement, en conservant la surface de l'API.

Exemple :

utils.js
export default {
authorize: () => 'token',
isAuthorized: secret => secret === 'wizard',
};
__tests__/automock.test.js
import utils from '../utils';

test('if utils mocked automatically', () => {
// Les méthodes publiques de `utils` sont maintenant des fonctions simulées
expect(utils.authorize.mock).toBeTruthy();
expect(utils.isAuthorized.mock).toBeTruthy();

// Vous pouvez les fournir avec votre propre implémentation
// ou passer la valeur de retour attendue
utils.authorize.mockReturnValue('mocked_token');
utils.isAuthorized.mockReturnValue(true);

expect(utils.authorize()).toBe('mocked_token');
expect(utils.isAuthorized('not_wizard')).toBeTruthy();
});
remarque

Les modules Node sont automatiquement simulés lorsque vous avez un simulateur manuel en place (par exemple : __mocks__/lodash.js). Plus d'infos ici.

Les modules du noyau, comme fs, ne sont pas simulĂ©s par dĂ©faut. Ils peuvent ĂȘtre simulĂ©s explicitement, par exemple jest.mock('fs').

bail [number | boolean]​

Par dĂ©faut : 0

Par dĂ©faut, Jest exĂ©cute tous les tests et produit toutes les erreurs dans la console Ă  la fin. L'option de configuration bail peut ĂȘtre utilisĂ©e ici pour que Jest arrĂȘte de lancer des tests aprĂšs n Ă©checs. DĂ©finir bail Ă  true est la mĂȘme chose que dĂ©finir bail Ă  1.

cacheDirectory [string]​

Par dĂ©faut : "/tmp/<path>"

Le rĂ©pertoire oĂč Jest doit stocker ses informations de dĂ©pendance en cache.

Avant d'exĂ©cuter les tests, Jest tente d’analyser votre arborescence de dĂ©pendances (en amont) et met ces rĂ©sultats en cache afin d’allĂ©ger les accĂšs au systĂšme de fichiers qui doivent se produire lors de l’exĂ©cution des tests. Cette option de configuration vous permet de personnaliser le rĂ©pertoire oĂč Jest stocke ces donnĂ©es.

clearMocks [boolean]​

Par dĂ©faut : false

Efface automatiquement les appels, les instances, les contextes et les rĂ©sultats des simulations avant chaque test. Équivalent Ă  l'appel de jest.clearAllMocks() avant chaque test. Cela ne supprime aucune implĂ©mentation simulĂ©e qui aurait pu ĂȘtre fournie.

collectCoverage [boolean]​

Par dĂ©faut : false

Indique si les informations de couverture doivent ĂȘtre collectĂ©es lors de l'exĂ©cution du test. Étant donnĂ© que cette opĂ©ration modifie tous les fichiers exĂ©cutĂ©s avec des instructions de collecte de couverture, elle peut ralentir considĂ©rablement vos tests.

Jest est livrĂ© avec deux fournisseurs de couverture : babel (par dĂ©faut) et v8. Consultez l'option coverageProvider pour plus de dĂ©tails.

info

Les fournisseurs de couverture babel et v8 utilisent /* istanbul ignorent la suivante */ et /* c8 ignorent les commentaires suivants */ pour exclure les lignes des rapports de couverture, respectivement. Pour plus d'informations, vous pouvez consulter la documentation istanbuljs et la documentation c8.

collectCoverageFrom [array]​

Par dĂ©faut : undefined

Un tableau de patterns glob indiquant un ensemble de fichiers pour lesquels des informations de couverture doivent ĂȘtre collectĂ©es. Si un fichier correspond au pattern glob spĂ©cifiĂ©, des informations de couverture seront collectĂ©es pour ce fichier, mĂȘme si aucun test n'existe pour ce fichier et qu'il n'est jamais requis dans la suite de tests.

/** @type {import('jest').Config} */
const config = {
collectCoverageFrom: [
'**/*.{js,jsx}',
'!**/node_modules/**',
'!**/vendor/**',
],
};

module.exports = config;

Ceci collectera les informations de couverture pour tous les fichiers à l'intérieur du rootDir du projet, sauf ceux qui correspondent à **/node_modules/** ou **/vendor/**.

astuce

Chaque pattern glob est appliqué dans l'ordre dans lequel ils sont spécifiés dans la configuration. Par exemple ["!**/__tests__/**", "**/*.js"] n'exclura pas __tests__ car la négation est écrasée par le second pattern. Pour que le glob négatif fonctionne dans cet exemple, il doit venir aprÚs **/*.js.

remarque

Cette option nécessite que collectCoverage soit défini à true ou que Jest ait été appelé avec l'option --coverage.

Help:

If you are seeing coverage output such as...

=============================== Coverage summary ===============================
Statements : Unknown% ( 0/0 )
Branches : Unknown% ( 0/0 )
Functions : Unknown% ( 0/0 )
Lines : Unknown% ( 0/0 )
================================================================================
Jest: Coverage data for global was not found.

Il est trĂšs probable que vos patterns glob ne correspondent Ă  aucun fichier. Reportez-vous Ă  la documentation de micromatch pour vous assurer que vos globs sont compatibles.

coverageDirectory [string]​

Par dĂ©faut : undefined

Le rĂ©pertoire oĂč Jest doit Ă©crire les fichiers de couverture.

coveragePathIgnorePatterns [array<string>]​

Par dĂ©faut : ["/node_modules/"]

Un tableau de chaßnes de patterns regexp qui sont comparées à tous les chemins de fichiers avant d'exécuter le test. Si le chemin du fichier correspond à l'un des patterns, l'information de couverture sera ignorée.

Ces chaĂźnes de patterns correspondent au chemin d'accĂšs complet. Utilisez la chaine de caractĂšre <rootDir> pour inclure le chemin vers la racine de votre projet, pour l'empĂȘcher d'ignorer accidentellement tous vos fichiers dans les environnements qui auraient un rĂ©pertoire racine diffĂ©rent. Exemple : ["<rootDir>/build/", "<rootDir>/node_modules/"].

coverageProvider [string]​

Indique quel fournisseur doit ĂȘtre utilisĂ© pour instrumenter le code pour la couverture. Les valeurs autorisĂ©es sont babel (par dĂ©faut) ou v8.

coverageReporters [array<string | [string, options]>]​

Default: ["clover", "json", "lcov", "text"]

Une liste de noms de rapporteurs que Jest utilise lors de la rĂ©daction de rapports de couverture. N'importe quel rapporteur istanbul peut ĂȘtre utilisĂ©.

astuce

La configuration de cette option remplace les valeurs par défaut. Ajoutez "text" ou "text-summary" pour voir un résumé de la couverture dans la sortie console.

Des options supplĂ©mentaires peuvent ĂȘtre passĂ©es en utilisant la forme tuple. Par exemple, vous pouvez cacher les lignes de dĂ©claration de couverture pour tous les fichiers couverts :

/** @type {import('jest').Config} */
const config = {
coverageReporters: ['clover', 'json', 'lcov', ['text', {skipFull: true}]],
};

module.exports = config;

For more information about the options object shape refer to CoverageReporterWithOptions type in the type definitions.

coverageThreshold [object]​

Par dĂ©faut : undefined

Cela servira Ă  configurer le seuil minimum pour les rĂ©sultats de la couverture. Les seuils peuvent ĂȘtre spĂ©cifiĂ©s comme global, comme glob, et comme un rĂ©pertoire ou un chemin de fichier. Si les seuils ne sont pas atteints, jest Ă©chouera. Les seuils spĂ©cifiĂ©s en tant que nombre positif sont considĂ©rĂ©s comme le pourcentage minimum requis. Les seuils spĂ©cifiĂ©s comme un nombre nĂ©gatif reprĂ©sentent le nombre maximum d'entitĂ©s non couvertes autorisĂ©es.

Par exemple, avec la configuration suivante, jest Ă©chouera si la couverture des branches, des lignes et des fonctions est infĂ©rieure Ă  80%, ou s'il y a plus de 10 dĂ©clarations non couvertes :

/** @type {import('jest').Config} */
const config = {
coverageThreshold: {
global: {
branches: 80,
functions: 80,
lines: 80,
statements: -10,
},
},
};

module.exports = config;

Si des globs ou des chemins sont spécifiés à cÎté de global, les données de couverture pour les chemins correspondants seront soustraites de la couverture globale et les seuils seront appliqués indépendamment. Les seuils pour les globs sont appliqués à tous les fichiers correspondant à la glob. Si le fichier spécifié par le chemin d'accÚs n'est pas trouvé, une erreur sera retournée.

Par exemple, avec la configuration suivante :

/** @type {import('jest').Config} */
const config = {
coverageThreshold: {
global: {
branches: 50,
functions: 50,
lines: 50,
statements: 50,
},
'./src/components/': {
branches: 40,
statements: 40,
},
'./src/reducers/**/*.js': {
statements: 90,
},
'./src/api/very-important-module.js': {
branches: 100,
functions: 100,
lines: 100,
statements: 100,
},
},
};

module.exports = config;

Jest Ă©chouera si :

  • Le rĂ©pertoire ./src/composants a une couverture de branche ou pour les instructions infĂ©rieure Ă  40%.
  • Un des fichiers correspondant au glob ./src/reducers/**/*.js a une couverture des instructions infĂ©rieure Ă  90%.
  • Le fichier ./src/api/very-important-module.js a une couverture infĂ©rieure Ă  100%.
  • Tous les autres fichiers combinĂ©s ont une couverture infĂ©rieure Ă  50% (global).

dependencyExtractor [string]​

Par dĂ©faut : undefined

Cette option permet l'utilisation d'un extracteur de dĂ©pendance personnalisĂ©. Il doit s'agir d'un module de node qui exporte un objet avec une fonction extract. Par exemple :

const crypto = require('crypto');
const fs = require('fs');

module.exports = {
extract(code, filePath, defaultExtract) {
const deps = defaultExtract(code, filePath);
// Scanne le fichier et ajoute les dépendances dans `deps` (qui est un `Set`)
return deps;
},
getCacheKey() {
return crypto
.createHash('md5')
.update(fs.readFileSync(__filename))
.digest('hex');
},
};

La fonction extract doit retourner un itérable (Array, Set, etc.) avec les dépendances trouvées dans le code.

Ce module peut Ă©galement contenir une fonction getCacheKey pour gĂ©nĂ©rer une clĂ© de cache afin de dĂ©terminer si la logique a changĂ© et si tous les artefacts mis en cache qui s'appuient sur elle doivent ĂȘtre retirĂ©s.

displayName [string, object]​

par défaut : undefined

Permet de placer un libellĂ© Ă  cĂŽtĂ© d'un test en cours d'exĂ©cution. Cela devient plus utile dans les dĂ©pĂŽts multi-projets oĂč il peut y avoir de nombreux fichiers de configuration jest. Ceci indique visuellement Ă  quel projet appartient un test.

/** @type {import('jest').Config} */
const config = {
displayName: 'CLIENT',
};

module.exports = config;

Alternativement, un objet avec les propriĂ©tĂ©s name et color peut ĂȘtre passĂ©. Cela permet une configuration personnalisĂ©e de la couleur de fond de displayName. displayName est blanc par dĂ©faut quand sa valeur est une chaĂźne. Jest utilise chalk pour fournir la couleur. Ainsi, toutes les options valides pour les couleurs supportĂ©es par chalk sont Ă©galement supportĂ©es par jest.

/** @type {import('jest').Config} */
const config = {
displayName: {
name: 'CLIENT',
color: 'blue',
},
};

module.exports = config;

errorOnDeprecated [boolean]​

Par dĂ©faut : false

Fait en sorte que l'appel d'API obsolÚtes génÚre des messages d'erreur utiles. Utile pour faciliter le processus de mise à jour.

extensionsToTreatAsEsm [array<string>]​

Par dĂ©faut : []

Jest exécutera les fichiers .mjs et .js avec le champ type de package.json le plus proche défini sur module en tant que modules ECMAScript. Si vous avez d'autres fichiers qui devraient s'exécuter avec ESM natif, vous devez spécifier leur extension de fichier ici.

/** @type {import('jest').Config} */
const config = {
extensionsToTreatAsEsm: ['.ts'],
};

module.exports = config;
attention

Le support ESM de Jest est encore expérimental, voir sa documentation pour plus de détails.

fakeTimers [object]​

Par dĂ©faut : {}

Les faux temporisateurs peuvent ĂȘtre utiles lorsqu'un morceau de code dĂ©finit un long dĂ©lai d'attente que nous ne voulons pas attendre dans un test. Pour plus de dĂ©tails, consultez le guide des faux temporisateurs et la documentation API.

Cette option fournit la configuration par dĂ©faut des faux temporisateurs pour tous les tests. L'appel Ă  jest.useFakeTimers() dans un fichier de test utilisera ces options ou les remplacera si un objet de configuration est passĂ©. Par exemple, vous pouvez dire Ă  Jest de conserver l'implĂ©mentation originale de process.nextTick() et ajuster la limite des temporisateurs rĂ©cursifs qui seront exĂ©cutĂ©s :

/** @type {import('jest').Config} */
const config = {
fakeTimers: {
doNotFake: ['nextTick'],
timerLimit: 1000,
},
};

module.exports = config;
fakeTime.test.js
// installe de faux temporisateurs pour ce fichier en utilisant les options de la configuration Jest
jest.useFakeTimers();

test('augmente la limite des temporisateurs récursifs pour ce test et les tests suivants', () => {
jest.useFakeTimers({timerLimit: 5000});
// ...
});
astuce

Au lieu d'inclure jest.useFakeTimers() dans chaque fichier de test, vous pouvez activer les faux temporisateurs globalement pour tous les tests dans votre configuration de Jest :

/** @type {import('jest').Config} */
const config = {
fakeTimers: {
enableGlobally: true,
},
};

module.exports = config;

Options de configuration :

type FakeableAPI =
| 'Date'
| 'hrtime'
| 'nextTick'
| 'performance'
| 'queueMicrotask'
| 'requestAnimationFrame'
| 'cancelAnimationFrame'
| 'requestIdleCallback'
| 'cancelIdleCallback'
| 'setImmediate'
| 'clearImmediate'
| 'setInterval'
| 'clearInterval'
| 'setTimeout'
| 'clearTimeout';

type ModernFakeTimersConfig = {
/**
* Si défini à `true` tous les temporisateurs seront automatiquement avancés de 20 millisecondes
* toutes les 20 millisecondes. Un delta de temps personnalisĂ© peut ĂȘtre fourni en passant un nombre.
* La valeur par défaut est `false`.
*/
advanceTimers?: boolean | number;
/**
* Liste des noms des APIs qui ne doivent pas ĂȘtre falsifiĂ©s. La valeur par dĂ©faut est `[]`, ce qui signifie que
* toutes les APIs sont falsifiées.
*/
doNotFake?: Array<FakeableAPI>;
/** Si les faux temporisateurs doivent ĂȘtre activĂ©s pour tous les fichiers de test. La valeur par dĂ©faut est `false`. */
enableGlobally?: boolean;
/**
* Utilise l'ancienne implémentation des faux temporisateurs au lieu de celle supportée par `@sinonjs/fake-timers`.
* La valeur par défaut est `false`.
*/
legacyFakeTimers?: boolean;
/** Sets current system time to be used by fake timers, in milliseconds. La valeur par défaut est `Date.now()`. */
now?: number;
/** Nombre maximum de temporisateurs récursifs qui seront exécutés. La valeur par défaut est `100_000` temporisateurs. */
timerLimit?: number;
};
Les anciens faux temporisateurs

Pour certaines raisons, il se peut que vous deviez utiliser une ancienne implĂ©mentation de faux temporisateurs. Voici comment l'activer globalement (les options supplĂ©mentaires ne sont pas prises en charge) :

/** @type {import('jest').Config} */
const config = {
fakeTimers: {
enableGlobally: true,
legacyFakeTimers: true,
},
};

module.exports = config;

forceCoverageMatch [array<string>]​

Par dĂ©faut : ['']

Les fichiers de test sont normalement ignorés de la collecte de la couverture de code. Avec cette option, vous pouvez écraser ce comportement et inclure les fichiers ignorés dans la couverture de code.

Par exemple, si vous avez des tests dans des fichiers sources nommés avec l'extension .t.js comme suit :

sum.t.js
export function sum(a, b) {
return a + b;
}

if (process.env.NODE_ENV === 'test') {
test('sum', () => {
expect(sum(1, 2)).toBe(3);
});
}

Vous pouvez collecter la couverture de ces fichiers avec le paramĂštre forceCoverageMatch.

/** @type {import('jest').Config} */
const config = {
forceCoverageMatch: ['**/*.t.js'],
};

module.exports = config;

globals [object]​

Par dĂ©faut : {}

Un ensemble de variables globales qui doivent ĂȘtre disponibles dans tous les environnements de test.

Par exemple, ce qui suit crĂ©e une variable globale __DEV__ dĂ©finie Ă  true dans tous les environnements de test :

/** @type {import('jest').Config} */
const config = {
globals: {
__DEV__: true,
},
};

module.exports = config;
remarque

If you specify a global reference value (like an object or array) here, and some code mutates that value in the midst of running a test, that mutation will not be persisted across test runs for other test files. De plus, l'objet globals doit ĂȘtre sĂ©rialisable en json, donc il ne peut pas ĂȘtre utilisĂ© pour spĂ©cifier des fonctions globales. Pour cela, vous devez utiliser setupFiles.

globalSetup [string]​

Par dĂ©faut : undefined

Cette option permet l'utilisation d'un module de configuration global personnalisĂ©, qui doit exporter une fonction (elle peut ĂȘtre sync ou async). The function will be triggered once before all test suites and it will receive two arguments: Jest's globalConfig and projectConfig.

info

Un module de configuration global configuré dans un projet (à l'aide d'un runner multi-projets) ne sera déclenché que lorsque vous exécuterez au moins un test de ce projet.

Toute variable globale dĂ©finie par globalSetup ne peut ĂȘtre lue que dans globalTeardown. Vous ne pouvez pas rĂ©cupĂ©rer les globales dĂ©finies ici dans vos suites de test.

Alors que la transformation du code est appliquée au fichier d'installation lié, Jest ne transformera pas tout code dans node_modules. Cela est dû à la nécessité de charger les transformateurs réels (par exemple babel ou typescript) pour effectuer la transformation.

setup.js
module.exports = async function (globalConfig, projectConfig) {
console.log(globalConfig.testPathPattern);
console.log(projectConfig.cache);

// Définit la référence à mongod afin de fermer le serveur pendant le nettoyage.
globalThis.__MONGOD__ = mongod;
};
teardown.js
module.exports = async function (globalConfig, projectConfig) {
console.log(globalConfig.testPathPattern);
console.log(projectConfig.cache);

await globalThis.__MONGOD__.stop();
};

globalTeardown [string]​

Par dĂ©faut : undefined

Cette option permet l'utilisation d'un module de nettoyage global personnalisĂ©, qui doit exporter une fonction (elle peut ĂȘtre sync ou async). The function will be triggered once after all test suites and it will receive two arguments: Jest's globalConfig and projectConfig.

info

Un module de nettoyage global configuré dans un projet (à l'aide d'un runner multi-projets) ne sera déclenché que lorsque vous exécuterez au moins un test de ce projet.

La mĂȘme mise en garde concernant la transformation des node_modules que pour globalSetup s'applique Ă  globalTeardown.

haste [object]​

Par dĂ©faut : undefined

Ceci sera utilisĂ© pour configurer le comportement de jest-haste-map, le systĂšme d'exploration de fichiers internes de Jest. Les options suivantes sont prises en charges :

type HasteConfig = {
/** Si vous souhaitez hacher les fichiers en utilisant SHA-1. */
computeSha1?: boolean;
/** La plateforme à utiliser par défaut, par exemple 'ios'. */
defaultPlatform?: string | null;
/** Forcer l'utilisation des API `fs` de Node plutĂŽt que de se lancer dans `find` */
forceNodeFilesystemAPI? boolean ;
/**
* Suivre ou non les liens symboliques lors de l'indexation des fichiers.
* Cette option ne peut pas ĂȘtre utilisĂ©e dans les projets qui utilisent watchman.
* Les projets avec la valeur `watchman` à true seront en erreur si cette option est définie à true.
*/
enableSymlinks?: boolean;
/** Chemin vers une implémentation personnalisée de Haste. */
hasteImplModulePath?: string;
/** Toutes les plateformes Ă  cibler, par exemple ['ios', 'android']. */
platforms?: Array<string>;
/** Whether to throw an error on module collision. */
throwOnModuleCollision?: boolean;
/** Module HasteMap personnalisé */
hasteMapModulePath?: string;
/** S'il faut conserver tous les fichiers, autorisant par exemple la recherche des tests dans `node_modules`. */
retainAllFiles?: boolean;
};

injectGlobals [boolean]​

Par dĂ©faut : true

Insére les globales de Jest (expect, test, describe, beforeEach etc.) dans l'environnement global. Si vous définissez cette valeur à false, vous devez par exemple importer à partir de @jest/globals.

import {expect, jest, test} from '@jest/globals';

jest.useFakeTimers();

test('un test', () => {
expect(Date.now()).toBe(0);
});
remarque

Cette option n'est prise en charge qu'en utilisant le runner de test jest-circus par défaut.

maxConcurrency [number]​

Par dĂ©faut : 5

Un nombre limitant le nombre de tests qui sont autorisĂ©s Ă  s'exĂ©cuter en mĂȘme temps lors de l'utilisation de test.concurrent. Tout test dĂ©passant cette limite sera mis en file d'attente et exĂ©cutĂ© dĂšs qu'un sera libĂ©rĂ©.

maxWorkers [number | string]​

SpĂ©cifie le maximum de processus que l'orchestrateur de processus lancera pour exĂ©cuter les tests. En mode d'exĂ©cution simple, il s'agit par dĂ©faut du nombre de cƓurs disponibles sur votre machine, moins un pour le thread principal. En mode surveillance, il s'agit par dĂ©faut de la moitiĂ© des cƓurs disponibles sur votre machine afin de s'assurer que Jest reste discret et ne paralyse pas votre machine. Il peut ĂȘtre utile d'utiliser cette option dans les environnements avec des ressources limitĂ©es comme les environnements de CI, mais la valeur par dĂ©faut devrait ĂȘtre suffisante pour la plupart des cas d’utilisation.

Pour les environnements avec des processeurs disponibles variables, vous pouvez utiliser une configuration basĂ©e sur le pourcentage :

/** @type {import('jest').Config} */
const config = {
maxWorkers: '50%',
};

module.exports = config;

moduleDirectories [array<string>]​

Par dĂ©faut : ["node_modules"]

Un tableau de noms de rĂ©pertoires Ă  rechercher de maniĂšre rĂ©cursive Ă  partir de l'emplacement du module requis. DĂ©finir cette option va surcharger la valeur par dĂ©faut, si vous souhaitez toujours rechercher node_modules pour les paquets, incluez-le avec toutes les autres options :

/** @type {import('jest').Config} */
const config = {
moduleDirectories: ['node_modules', 'bower_components'],
};

module.exports = config;
attention

It is discouraged to use '.' as one of the moduleDirectories, because this prevents scoped packages such as @emotion/react from accessing packages with the same subdirectory name (react). See this issue for more details. In most cases, it is preferable to use the moduleNameMapper configuration instead.

moduleFileExtensions [array<string>]​

Par dĂ©faut : ["js", "mjs", "cjs", "jsx", "ts", "tsx", "json", "node"]

Un tableau d'extensions de fichiers que vos modules utilisent. Si vous demandez des modules sans spécifier d'extension de fichier, voici les extensions que Jest recherchera, dans l'ordre de gauche à droite.

Nous recommandons de placer les extensions les plus couramment utilisées dans votre projet sur la gauche, donc si vous utilisez TypeScript, vous pouvez envisager de déplacer "ts" et/ou "tsx" au début du tableau.

moduleNameMapper [object<string, string | array<string>>]​

Par dĂ©faut : null

Une correspondance entre les expressions réguliÚres et les noms de modules ou les tableaux de noms de modules, qui permet d'extraire des ressources, comme des images ou des styles, avec un seul module.

Les modules qui sont associés à un alias sont dé-simulés par défaut, que la simulation automatique soit activé ou non.

Utilisez le jeton de chaßne <rootDir> pour faire référence à la valeur rootDir si vous souhaitez utiliser les chemins d'accÚs aux fichiers.

En outre, vous pouvez substituer des groupes de regex capturés en utilisant des rétro références numérotées.

/** @type {import('jest').Config} */
const config = {
moduleNameMapper: {
'^image![a-zA-Z0-9$_-]+$': 'GlobalImageStub',
'^[./a-zA-Z0-9$_-]+\\.png$': '<rootDir>/RelativeImageStub.js',
'module_name_(.*)': '<rootDir>/substituted_module_$1.js',
'assets/(.*)': [
'<rootDir>/images/$1',
'<rootDir>/photos/$1',
'<rootDir>/recipes/$1',
],
},
};

module.exports = config;

L'ordre dans lequel les correspondances sont dĂ©finies est important. Les patterns sont vĂ©rifiĂ©s un par un jusqu'Ă  ce qu'il y en ait un qui convienne. La rĂšgle la plus spĂ©cifique doit ĂȘtre citĂ©e en premier. C'est Ă©galement vrai pour les tableaux de noms de modules.

info

Si vous fournissez le nom du module sans les limites ^$, cela peut provoquer des erreurs difficiles Ă  repĂ©rer. Par exemple : relay remplacera tous les modules qui contiennent relay comme une sous-chaĂźne dans son nom : relay, react-relay et graphql-relay seront tous pointĂ©s sur votre stub.

modulePathIgnorePatterns [array<string>]​

Par dĂ©faut : []

Un tableau de chaĂźnes de patterns regexp qui sont comparĂ©es Ă  tous les chemins de modules avant que ces chemins ne soient considĂ©rĂ©s comme « visibles Â» par le chargeur de modules. Si le chemin d'un module correspond Ă  un des patterns, il ne sera pas possible de faire un require() dans l'environnement de test.

Ces chaĂźnes de patterns correspondent au chemin d'accĂšs complet. Utilisez la chaine de caractĂšre <rootDir> pour inclure le chemin vers la racine de votre projet, pour l'empĂȘcher d'ignorer accidentellement tous vos fichiers dans les environnements qui auraient un rĂ©pertoire racine diffĂ©rent.

/** @type {import('jest').Config} */
const config = {
modulePathIgnorePatterns: ['<rootDir>/build/'],
};

module.exports = config;

modulePaths [array<string>]​

Par dĂ©faut : []

C'est une API alternative à la définition de la variable d'environnement NODE_PATH, modulePaths est un tableau de chemins absolus vers des emplacements supplémentaires à rechercher lors de la résolution des modules. Utilisez le jeton de chaßne <rootDir> pour inclure le chemin vers le répertoire racine de votre projet.

/** @type {import('jest').Config} */
const config = {
modulePaths: ['<rootDir>/app/'],
};

module.exports = config;

notify [boolean]​

Par dĂ©faut : false

Active les notifications de l'OS pour les rĂ©sultats de test. Pour afficher les notifications, Jest a besoin du package node-notifier qui doit ĂȘtre installĂ© en plus :

npm install --save-dev node-notifier
astuce

Sur macOS, n'oubliez pas d'autoriser les notifications depuis le terminal-notifier sous Préférences SystÚme > Notifications & Focus.

Sous Windows, node-notifier crée une nouvelle entrée dans le menu de démarrage à la premiÚre utilisation et n'affiche pas la notification. Les notifications seront affichées correctement lors des exécutions suivantes.

notifyMode [string]​

Par dĂ©faut : failure-change

Spécifie le mode de notification. Nécessite notify : true.

Modes​

  • always : toujours envoyer une notification.
  • failure : envoyer une notification lorsque les tests Ă©chouent.
  • success : envoyer une notification lorsque les tests rĂ©ussissent.
  • change : envoyer une notification lorsque le statut a changĂ©.
  • success-change : envoyer une notification lorsque les tests rĂ©ussissent ou une fois lorsqu'ils Ă©chouent.
  • failure-change : envoyer une notification lorsque les tests Ă©chouent ou une fois lorsqu'ils rĂ©ussissent.

openHandlesTimeout [number]​

Default: 1000

Print a warning indicating that there are probable open handles if Jest does not exit cleanly this number of milliseconds after it completes. Use 0 to disable the warning.

preset [string]​

Par dĂ©faut : undefined

Un preset qui est utilisé comme base pour la configuration de Jest. Un preset doit pointer vers un module npm qui a un fichier jest-preset.json, jest-preset.js, jest-preset.cjs ou jest-preset.mjs à la racine.

Par exemple, ce preset foo-bar/jest-preset.js sera configurĂ© comme suit :

/** @type {import('jest').Config} */
const config = {
preset: 'foo-bar',
};

module.exports = config;

Les presets peuvent Ă©galement ĂȘtre relatifs aux chemins du systĂšme de fichiers:

/** @type {import('jest').Config} */
const config = {
preset: './node_modules/foo-bar/jest-preset.js',
};

module.exports = config;
info

If you also have specified rootDir, the resolution of this file will be relative to that root directory.

prettierPath [string]​

Par dĂ©faut : 'prettier'

Définit le chemin vers le module de node prettier utilisé pour mettre à jour les snapshots en ligne.

Prettier version 3 n'est pas pris en charge !

You can either pass prettierPath: null in your config to disable using prettier if you don't need it, or use v2 of Prettier solely for Jest.

package.json
{
"devDependencies": {
"prettier-2": "npm:prettier@^2"
}
}
/** @type {import('jest').Config} */
const config = {
prettierPath: require.resolve('prettier-2'),
};

module.exports = config;

Nous espérons prendre en charge Prettier v3 de maniÚre transparente dans une prochaine version de Jest. See this tracking issue.

projects [array<string | ProjectConfig>]​

Par dĂ©faut : undefined

Lorsque la configuration projects est fournie avec un tableau de chemins ou de patterns glob, Jest exĂ©cutera les tests dans tous les projets spĂ©cifiĂ©s en mĂȘme temps. C'est idĂ©al pour les monorepos ou lorsque vous travaillez sur plusieurs projets en mĂȘme temps.

/** @type {import('jest').Config} */
const config = {
projects: ['<rootDir>', '<rootDir>/examples/*'],
};

module.exports = config;

Cet exemple de configuration exĂ©cutera Jest dans le rĂ©pertoire racine ainsi que dans tous les dossiers du rĂ©pertoire examples. Vous pouvez avoir un nombre illimitĂ© de projets en cours d'exĂ©cution dans la mĂȘme instance Jest.

La fonctionnalitĂ© des projets peut Ă©galement ĂȘtre utilisĂ©e pour exĂ©cuter plusieurs configurations ou plusieurs runners. Pour cela, vous pouvez passer un tableau d'objets de configuration. Par exemple, pour exĂ©cuter Ă  la fois des tests et ESLint (via jest-runner-eslint) dans la mĂȘme invocation de Jest :

/** @type {import('jest').Config} */
const config = {
projects: [
{
displayName: 'test',
},
{
displayName: 'lint',
runner: 'jest-runner-eslint',
testMatch: ['<rootDir>/**/*.js'],
},
],
};

module.exports = config;
astuce

Lors de l'utilisation d'un runner multi-projets, il est recommandé d'ajouter un displayName pour chaque projet. Cela affichera le displayName d'un projet à cÎté de ses tests.

remarque

With the projects option enabled, Jest will copy the root-level configuration options to each individual child configuration during the test run, resolving its values in the child's context. This means that string tokens like <rootDir> will point to the child's root directory even if they are defined in the root-level configuration.

randomize [boolean]​

Par dĂ©faut : false

The equivalent of the --randomize flag to randomize the order of the tests in a file.

reporters [array<moduleName | [moduleName, options]>]​

Par dĂ©faut : undefined

Utilisez cette option de configuration pour ajouter des rapporteurs Ă  Jest. Il doit s'agir d'une liste de noms de rapporteurs, des options supplĂ©mentaires peuvent ĂȘtre passĂ©es Ă  un rapporteur en utilisant la forme tuple :

/** @type {import('jest').Config} */
const config = {
reporters: [
'default',
['<rootDir>/custom-reporter.js', {banana: 'yes', pineapple: 'no'}],
],
};

module.exports = config;

Rapporteur par dĂ©faut​

Si des rapporteurs personnalisĂ©s sont spĂ©cifiĂ©s, le rapporteur par dĂ©faut de Jest sera Ă©crasĂ©. Si vous souhaitez le conserver, 'default' doit ĂȘtre passĂ© comme nom de rapporteur :

/** @type {import('jest').Config} */
const config = {
reporters: [
'default',
['jest-junit', {outputDirectory: 'reports', outputName: 'report.xml'}],
],
};

module.exports = config;

Rapporteur GitHub Actions​

If included in the list, the built-in GitHub Actions Reporter will annotate changed files with test failure messages and (if used with 'silent: false') print logs with github group features for easy navigation. Note that 'default' should not be used in this case as 'github-actions' will handle that already, so remember to also include 'summary'. If you wish to use it only for annotations simply leave only the reporter without options as the default value of 'silent' is 'true':

/** @type {import('jest').Config} */
const config = {
reporters: [['github-actions', {silent: false}], 'summary'],
};

module.exports = config;

Rapporteur summary​

Le rapport summary affiche le rĂ©sumĂ© de tous les tests. Il fait partie du rapporteur par dĂ©faut, donc il sera activĂ© si 'default' est inclus dans la liste. Par exemple, vous pouvez l'utiliser en tant que rapporteur autonome au lieu de celui par dĂ©faut, ou en combinaison avec le rapporteur Silent :

/** @type {import('jest').Config} */
const config = {
reporters: ['jest-silent-reporter', 'summary'],
};

module.exports = config;

The summary reporter accepts options. Since it is included in the default reporter you may also pass the options there.

/** @type {import('jest').Config} */
const config = {
reporters: [['default', {summaryThreshold: 10}]],
};

module.exports = config;

The summaryThreshold option behaves in the following way, if the total number of test suites surpasses this threshold, a detailed summary of all failed tests will be printed after executing all the tests. It defaults to 20.

Rapporteurs personnalisĂ©s​

astuce

Vous avez faim de rapporteurs ? Jetez un coup d'Ɠil Ă  la longue liste de rapporteurs gĂ©niaux de Awesome Jest.

Custom reporter module must export a class that takes globalConfig, reporterOptions and reporterContext as constructor arguments:

custom-reporter.js
class CustomReporter {
constructor(globalConfig, reporterOptions, reporterContext) {
this._globalConfig = globalConfig;
this._options = reporterOptions;
this._context = reporterContext;
}

onRunComplete(testContexts, results) {
console.log('Custom reporter output:');
console.log('global config:', this._globalConfig);
console.log('options for this reporter from Jest config:', this._options);
console.log('reporter context passed from test scheduler:', this._context);
}

// Optionally, reporters can force Jest to exit with non zero code by returning
// an `Error` from `getLastError()` method.
getLastError() {
if (this._shouldFail) {
return new Error('Erreur personnalisĂ©e signalĂ©e !');
}
}
}

module.exports = CustomReporter;
remarque

For the full list of hooks and argument types see the Reporter interface in packages/jest-reporters/src/types.ts.

resetMocks [boolean]​

Par dĂ©faut : false

RĂ©initialisation automatique de l'Ă©tat de la simulation avant chaque test. Équivalent Ă  l'appel de jest.resetAllMocks() avant chaque test. Cela conduira Ă  la destruction des implĂ©mentations fictives des simulations, mais ne rĂ©tablira pas leur implĂ©mentation initiale.

resetModules [boolean]​

Par dĂ©faut : false

Par dĂ©faut, chaque fichier de test obtient son propre registre de modules indĂ©pendant. L'activation de resetModules va un peu plus loin et rĂ©initialise le registre des modules avant d'exĂ©cuter chaque test individuel. Ceci est utile pour isoler les modules pour chaque test afin que l'Ă©tat du module local n'entre pas en conflit entre les tests. Cela peut ĂȘtre fait par programmation en utilisant jest.resetModules().

resolver [string]​

Par dĂ©faut : undefined

Cette option permet d'utiliser un rĂ©solveur personnalisĂ©. Ce rĂ©solveur doit ĂȘtre un module qui exporte soit :

  1. une fonction qui attend une chaĂźne comme premier argument pour le chemin Ă  rĂ©soudre et un objet d'options comme second argument. La fonction doit soit retourner un chemin d'accĂšs au module qui doit ĂȘtre rĂ©solu, soit lancer une erreur si le module est introuvable. ou
  2. un objet contenant des propriĂ©tĂ©s async et/ou sync. La propriĂ©tĂ© sync doit ĂȘtre une fonction avec la forme expliquĂ©e ci-dessus, et la propriĂ©tĂ© async doit Ă©galement ĂȘtre une fonction qui accepte les mĂȘmes arguments, mais renvoie une promesse qui se rĂ©sout avec le chemin vers le module ou se rejette avec une erreur.

L'objet d'options fourni aux rĂ©solveurs a la forme suivante :

type ResolverOptions = {
/** Répertoire à partir duquel commencer la résolution. */
basedir: string;
/** Liste des conditions d'exportation. */
conditions?: Array<string>;
/** Instance du résolveur par défaut. */
defaultResolver: (path: string, options: ResolverOptions) => string;
/** Liste des extensions de fichiers Ă  rechercher dans l'ordre. */
extensions?: Array<string>;
/** Liste des noms de répertoires à rechercher dans les modules récursivement. */
moduleDirectory?: Array<string>;
/** Liste de `require.paths` à utiliser si rien n'est trouvé dans `node_modules`. */
paths?: Array<string>;
/** Permet de transformer le contenu du `package.json` analysé. */
packageFilter?: (pkg: PackageJSON, file: string, dir: string) => PackageJSON;
/** Permet de transformer un chemin dans un package. */
pathFilter?: (pkg: PackageJSON, path: string, relativePath: string) => string;
/** RĂ©pertoire racine actuel. */
rootDir?: string;
};
astuce

Le defaultResolver passĂ© en option est le rĂ©solveur par dĂ©faut de Jest, ce qui peut ĂȘtre utile lorsque vous Ă©crivez votre propre rĂ©solveur. Il prend les mĂȘmes arguments que votre synchrone personnalisĂ©, par exemple (path, options) et renvoie une chaĂźne ou des exceptions.

Par exemple, si vous voulez respecter le champ "browser" de Browserify, vous pouvez utiliser le rĂ©solveur suivant :

resolver.js
const browserResolve = require('browser-resolve');

module.exports = browserResolve.sync;

Et ajoutez-le Ă  la configuration de Jest :

/** @type {import('jest').Config} */
const config = {
resolver: '<rootDir>/resolver.js',
};

module.exports = config;

En combinant defaultResolver et packageFilter nous pouvons implĂ©menter un package.json « prĂ©-processeur Â» qui nous permet de changer la façon dont le rĂ©solveur par dĂ©faut va rĂ©soudre les modules. Par exemple, imaginons que nous souhaitons utiliser le champ "module" s'il est prĂ©sent, sinon se rabattre sur "main" :

module.exports = (path, options) => {
// Apelle defaultResolver, ainsi nous utilisons son cache, sa gestion d'erreur, etc.
return options.defaultResolver(path, {
...options,
// Utilise packageFilter pour traiter `package.json` avant la résolution (voir https://www.npmjs.com/package/resolve#resolveid-opts-cb)
packageFilter: pkg => {
return {
...pkg,
// Modifie la valeur de `main` avant la résolution du paquet
main: pkg.module || pkg.main,
};
},
});
};

restoreMocks [boolean]​

Par dĂ©faut : false

Restauration automatique de l'Ă©tat de la simulation et l'implĂ©mentation avant chaque test. Équivalent Ă  l'appel de jest.restoreAllMocks() avant chaque test. Cela conduira Ă  la destruction des implĂ©mentations de tous les simulations et rĂ©tablira leur implĂ©mentation initiale.

rootDir [string]​

Par dĂ©faut : La racine du rĂ©pertoire contenant votre fichier de configuration ou le package.json ou le pwd si aucun package.json n'est trouvĂ©

Le répertoire racine dans lequel Jest doit rechercher les tests et les modules. Si vous placez votre configuration Jest à l'intérieur de votre package.json et que vous souhaitez que le répertoire racine soit celui de votre dépÎt, la valeur de ce paramÚtre de configuration sera par défaut le répertoire du package.json.

Souvent, vous voudrez dĂ©finir ce paramĂštre sur 'src' ou 'lib', correspondant Ă  l'endroit oĂč le code est stockĂ© dans votre dĂ©pĂŽt.

astuce

L'utilisation de '<rootDir>' comme jeton de chaßne dans tout autre paramÚtre de configuration basé sur le chemin fera référence à cette valeur. Par exemple, si vous voulez que l'entrée setupFiles pointe vers le fichier some-setup.js à la racine de votre projet, vous pouvez définir sa valeur à '<rootDir>/some-setup.js'.

roots [array<string>]​

Par dĂ©faut : ["<rootDir>"]

Une liste de chemins vers des répertoires que Jest devrait utiliser pour rechercher des fichiers.

Il y a des cas oĂč vous souhaitez que Jest ne cherche que dans un seul sous-rĂ©pertoire (comme le cas oĂč vous avez un rĂ©pertoire src/ dans votre dĂ©pĂŽt), mais l'empĂȘche d'accĂ©der au reste du dĂ©pĂŽt.

info

Tandis que rootDir est surtout utilisé comme un jeton à réutiliser dans d'autres options de configuration, roots est utilisé par les internes de Jest pour localiser les fichiers de test et les fichiers sources. Cela s'applique également lors de la recherche de simulations manuelles pour les modules de node_modules (__mocks__ devra résider dans l'une des roots).

Par dĂ©faut, roots a une seule entrĂ©e <rootDir> mais il y a des cas oĂč vous souhaitez avoir plusieurs racines dans un mĂȘme projet, par exemple roots : ["<rootDir>/src/", "<rootDir>/tests/"].

runner [string]​

Par dĂ©faut : "jest-runner"

Cette option vous permet d'utiliser un runner personnalisĂ© au lieu du runner de test par dĂ©faut de Jest. Exemples de runners inclus :

info

La valeur de la propriété runner peut omettre le préfixe jest-runner- du nom du paquet.

To write a test-runner, export a class with which accepts globalConfig in the constructor, and has a runTests method with the signature:

async function runTests(
tests: Array<Test>,
watcher: TestWatcher,
onStart: OnTestStart,
onResult: OnTestSuccess,
onFailure: OnTestFailure,
options: TestRunnerOptions,
): Promise<void>;

Si vous avez besoin de restreindre votre test-runner pour qu'il ne s'exĂ©cute qu'en sĂ©rie plutĂŽt que d'ĂȘtre exĂ©cutĂ© en parallĂšle, votre classe doit avoir la propriĂ©tĂ© isSerial dĂ©finie Ă  true.

sandboxInjectedGlobals [array<string>]​

astuce

Renommé en extraGlobals dans Jest 28.

Par dĂ©faut : undefined

Les fichiers de test s'exécutent à l'intérieur d'une vm, ce qui ralentit les appels aux propriétés contextuelles globales (par exemple Math). Avec cette option, vous pouvez spécifier des propriétés supplémentaires à définir à l'intérieur de la vm pour des recherches plus rapides.

Par exemple, si vos tests appellent souvent Math, vous pouvez le passer en définissant sandboxInjectedGlobals.

/** @type {import('jest').Config} */
const config = {
sandboxInjectedGlobals: ['Math'],
};

module.exports = config;
remarque

Cette option n'a aucun effet si vous utilisez l'ESM natif.

setupFiles [array]​

Par dĂ©faut : []

Une liste de chemins vers des modules qui exĂ©cutent du code pour configurer ou mettre en place l'environnement de test. Chaque setupFile sera exĂ©cutĂ© une fois par fichier de test. Puisque chaque test s'exĂ©cute dans son propre environnement, ces scripts seront exĂ©cutĂ©s dans l'environnement de test avant d'exĂ©cuter setupFilesAfterEnv et avant le code du test lui-mĂȘme.

astuce

Si votre script de configuration est un module CJS, il peut exporter une fonction asynchrone. Jest appellera la fonction et attendra son rĂ©sultat. Cela peut ĂȘtre utile pour rĂ©cupĂ©rer des donnĂ©es de maniĂšre asynchrone. Si le fichier est un module ESM, il suffit d'utiliser le await de niveau supĂ©rieur pour obtenir le mĂȘme rĂ©sultat.

setupFilesAfterEnv [array]​

Par dĂ©faut : []

Une liste de chemins vers des modules qui exĂ©cutent du code pour configurer ou paramĂ©trer le framework de test avant l'exĂ©cution de chaque fichier de test de la suite. Puisque setupFiles s'exĂ©cute avant que le framework de test soit installĂ© dans l'environnement, ce fichier script vous prĂ©sente l'opportunitĂ© d'exĂ©cuter du code immĂ©diatement aprĂšs l'installation du framework de test dans l'environnement mais avant le code du test lui-mĂȘme.

En d'autres termes, les modules setupFilesAfterEnv sont destinĂ©s au code qui se rĂ©pĂšte dans chaque fichier de test. L'installation du framework de test rend les globaux Jest, les objets jest et l'expect accessibles dans les modules. Par exemple, vous pouvez ajouter des comparateurs supplĂ©mentaires depuis la bibliothĂšque jest-extended ou appeler les hooks de paramĂ©trage et de dĂ©montage :

setup-jest.js
const matchers = require('jest-extended');
expect.extend(matchers);

afterEach(() => {
jest.useRealTimers();
});
/** @type {import('jest').Config} */
const config = {
setupFilesAfterEnv: ['<rootDir>/setup-jest.js'],
};

module.exports = config;

showSeed [boolean]​

Par dĂ©faut : false

The equivalent of the --showSeed flag to print the seed in the test report summary.

slowTestThreshold [number]​

Par dĂ©faut : 5

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

snapshotFormat [object]​

Par dĂ©faut : {escapeString: false, printBasicPrototype: false}

Permet de remplacer les options de formatage de snapshots spĂ©cifiques documentĂ©es dans le readme de pretty-format, Ă  l'exception de compareKeys et plugins. Par exemple, cette configuration permet au formateur de snapshot de ne pas afficher de prĂ©fixe pour "Object" et "Array" :

/** @type {import('jest').Config} */
const config = {
snapshotFormat: {
printBasicPrototype: false,
},
};

module.exports = config;
some.test.js
test('does not show prototypes for object and array inline', () => {
const object = {
array: [{hello: 'Danger'}],
};
expect(object).toMatchInlineSnapshot(`
{
"array": [
{
"hello": "Danger",
},
],
}
`);
});

snapshotResolver [string]​

Par dĂ©faut : undefined

The path to a module that can resolve test<->snapshot path. Cette option de configuration vous permet de personnaliser l'endroit oĂč Jest stocke les fichiers snapshot sur le disque.

custom-resolver.js
module.exports = {
// résout le chemin d'accÚs de test au snapshot
resolveSnapshotPath: (testPath, snapshotExtension) =>
testPath.replace('__tests__', '__snapshots__') + snapshotExtension,

//résout depuis le snapshot vers le chemin de test
resolveTestPath: (snapshotFilePath, snapshotExtension) =>
snapshotFilePath
.replace('__snapshots__', '__tests__')
.slice(0, -snapshotExtension.length),

// Exemple de chemin de test, utilisé pour vérifier la cohérence de l'implémentation ci-dessus
testPathForConsistencyCheck: 'some/__tests__/example.test.js',
};

snapshotSerializers [array<string>]​

Par dĂ©faut : []

Une liste de chemins d'accÚs aux modules de sérialisation des snapshots que Jest doit utiliser pour tester les snapshots.

Jest possÚde des sérialiseurs par défaut pour les types JavaScript intégrés, les éléments HTML (Jest 20.0.0+), ImmutableJS (Jest 20.0.0+) et pour les éléments React. Consultez le tutoriel sur le test de snapshot pour plus d'informations.

custom-serializer.js
module.exports = {
serialize(val, config, indentation, depth, refs, printer) {
return `Pretty foo: ${printer(val.foo)}`;
},

test(val) {
return val && Object.prototype.hasOwnProperty.call(val, 'foo');
},
};

printer est une fonction qui sérialise une valeur en utilisant les plugins existants.

Ajoutez custom-serializer Ă  votre configuration Jest :

/** @type {import('jest').Config} */
const config = {
snapshotSerializers: ['path/to/custom-serializer.js'],
};

module.exports = config;

Enfin les tests ressembleraient Ă  ceci :

test(() => {
const bar = {
foo: {
x: 1,
y: 2,
},
};

expect(bar).toMatchSnapshot();
});

Snapshot rendu :

Pretty foo: Object {
"x": 1,
"y": 2,
}
astuce

Pour rendre une dĂ©pendance explicite au lieu d'ĂȘtre implicite, vous pouvez appeler expect.addSnapshotSerializer pour ajouter un module pour un fichier de test individuel au lieu d'ajouter son chemin Ă  snapshotSerializers dans la configuration de Jest.

More about serializers API can be found here.

testEnvironment [string]​

Par dĂ©faut : "node"

L'environnement de test qui sera utilisé pour les tests. L'environnement par défaut dans Jest est un environnement Node.js. Si vous construisez une application web, vous pouvez utiliser à la place un environnement de type navigateur via jsdom.

En ajoutant un docblock @jest-environment en haut du fichier, vous pouvez spĂ©cifier un autre environnement Ă  utiliser pour tous les tests de ce fichier :

/**
* @jest-environment jsdom
*/

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

Vous pouvez crĂ©er votre propre module qui sera utilisĂ© pour configurer l'environnement de test. Le module doit exporter une classe avec les mĂ©thodes setup, teardown et getVmContext. Vous pouvez Ă©galement passer des variables de ce module Ă  vos suites de test en les assignant Ă  l'objet this.global – ceci les rendra disponibles dans vos suites de test comme variables globales. The constructor is passed globalConfig and projectConfig as its first argument, and testEnvironmentContext as its second.

The class may optionally expose an asynchronous handleTestEvent method to bind to events fired by jest-circus. Normally, jest-circus test runner would pause until a promise returned from handleTestEvent gets fulfilled, except for the next events: start_describe_definition, finish_describe_definition, add_hook, add_test or error (for the up-to-date list you can look at SyncEvent type in the types definitions). Cela est dû à des raisons de rétrocompatibilité et à la signature process.on('unhandledRejection', callback), mais cela ne devrait pas poser de problÚme pour la plupart des cas d'utilisation.

Tous les directives du docblock dans les fichiers de test seront transmises au constructeur de l'environnement et peuvent ĂȘtre utilisĂ©es pour la configuration de chaque test. Si la directive n'a pas de valeur, elle sera prĂ©sente dans l'objet avec sa valeur Ă©gale Ă  une chaĂźne vide. Si la directive n'est pas prĂ©sente, elle ne sera pas prĂ©sente dans l'objet.

Pour utiliser cette classe comme environnement personnalisĂ©, faites-y rĂ©fĂ©rence par son chemin complet dans le projet. Par exemple, si votre classe est stockĂ©e dans my-custom-environment.js dans un sous-dossier de votre projet, l'annotation pourrait ressembler Ă  ceci :

/**
* @jest-environment ./src/test/my-custom-environment
*/
info

TestEnvironment est un environnement de type bac à sable. Chaque suite de test déclenchera l'installation et le nettoyage dans son propre TestEnvironment.

Exemple :

// my-custom-environment
const NodeEnvironment = require('jest-environment-node').TestEnvironment;

class CustomEnvironment extends NodeEnvironment {
constructor(config, context) {
super(config, context);
console.log(config.globalConfig);
console.log(config.projectConfig);
this.testPath = context.testPath;
this.docblockPragmas = context.docblockPragmas;
}

async setup() {
await super.setup();
await someSetupTasks(this.testPath);
this.global.someGlobalObject = createGlobalObject();

// Will trigger if docblock contains @my-custom-pragma my-pragma-value
if (this.docblockPragmas['my-custom-pragma'] === 'my-pragma-value') {
// ...
}
}

async teardown() {
this.global.someGlobalObject = destroyGlobalObject();
await someTeardownTasks();
await super.teardown();
}

getVmContext() {
return super.getVmContext();
}

async handleTestEvent(event, state) {
if (event.name === 'test_start') {
// ...
}
}
}

module.exports = CustomEnvironment;
// my-test-suite
/**
* @jest-environment ./my-custom-environment
*/
let someGlobalObject;

beforeAll(() => {
someGlobalObject = globalThis.someGlobalObject;
});

testEnvironmentOptions [Object]​

Par dĂ©faut : {}

Options de l'environnement de test qui seront transmises à testEnvironment. Les options pertinentes dépendent de l'environnement.

For example, you can override options passed to jsdom:

/** @type {import('jest').Config} */
const config = {
testEnvironment: 'jsdom',
testEnvironmentOptions: {
html: '<html lang="zh-cmn-Hant"></html>',
url: 'https://jestjs.io/',
userAgent: 'Agent/007',
},
};

module.exports = config;

Les jest-environment-jsdom et jest-environment-node permettent tous deux de spécifier des customExportConditions, qui permettent de contrÎler quelles versions d'une bibliothÚque sont chargées à partir des exports dans package.json. jest-environment-jsdom a par défaut ['browser']. jest-environment-node a par défaut ['node', 'node-addons'].

/** @type {import('jest').Config} */
const config = {
testEnvironment: 'jsdom',
testEnvironmentOptions: {
customExportConditions: ['react-native'],
},
};

module.exports = config;

Ces options peuvent Ă©galement ĂȘtre passĂ©es dans un docblock, similaire Ă  testEnvironment. The string with options must be parseable by JSON.parse:

/**
* @jest-environment jsdom
* @jest-environment-options {"url": "https://jestjs.io/"}
*/

test('utilisez jsdom et définissez l\'URL dans ce fichier de test', () => {
expect(window.location.href).toBe('https://jestjs.io/');
});

testFailureExitCode [number]​

Par dĂ©faut : 1

Le code de sortie que Jest renvoie en cas d'Ă©chec du test.

info

Cela ne change pas le code de sortie en cas d'erreurs de Jest (par exemple, une configuration invalide).

testMatch [array<string>]​

(par dĂ©faut : [ "**/__tests__/**/*.[jt]s?(x)", "**/?(*.)+(spec|test).[jt]s?(x)" ])

Les patterns de glob que Jest utilise pour détecter les fichiers de test. Par défaut, il recherche les fichiers .js, .jsx, .ts et .tsx à l'intérieur des dossiers __tests__, ainsi que tout fichier dont le suffixe est .test ou .spec (par exemple Composant.test.js ou Composant.spec.js). Il trouvera également les fichiers appelés test.js ou spec.js.

Consultez le paquet micromatch pour obtenir des détails sur les patterns que vous pouvez spécifier.

Voir aussi testRegex [string | array<string>], mais notez que vous ne pouvez pas spécifier les deux options.

astuce

Chaque pattern glob est appliqué dans l'ordre dans lequel ils sont spécifiés dans la configuration. Par exemple ["!**/__fixtures__/**", "**/__tests__/**/*.js"] n'exclura pas __fixtures__ car la négation est remplacée par le second pattern. Pour que le glob négatif fonctionne dans cet exemple, il doit venir aprÚs **/__tests__/**/*.js.

testPathIgnorePatterns [array<string>]​

Par dĂ©faut : ["/node_modules/"]

Un tableau de chaßnes de patterns regexp qui sont comparées à tous les chemins de tests avant d'exécuter le test. Si le chemin du test correspond à un des patterns, il sera ignoré.

Ces chaĂźnes de patterns correspondent au chemin d'accĂšs complet. Utilisez la chaine de caractĂšre <rootDir> pour inclure le chemin vers la racine de votre projet, pour l'empĂȘcher d'ignorer accidentellement tous vos fichiers dans les environnements qui auraient un rĂ©pertoire racine diffĂ©rent. Exemple : ["<rootDir>/build/", "<rootDir>/node_modules/"].

testRegex [string | array<string>]​

Par dĂ©faut : (/__tests__/.*|(\\.|/)(test|spec))\\.[jt]sx?$

Le ou les patterns que Jest utilise pour détecter les fichiers de test. Par défaut, il recherche les fichiers .js, .jsx, .ts et .tsx à l'intérieur des dossiers __tests__, ainsi que tout fichier dont le suffixe est .test ou .spec (par exemple Composant.test.js ou Composant.spec.js). Il trouvera également les fichiers appelés test.js ou spec.js. Voir aussi testMatch [array<string>], mais notez que vous ne pouvez pas spécifier les deux options.

Ce qui suit est une visualisation des expressions rĂ©guliĂšres par dĂ©faut :

├── __tests__
│ └── component.spec.js # test
│ └── anything # test
├── package.json # not test
├── foo.test.js # test
├── bar.spec.jsx # test
└── component.js # not test
info

testRegex essaiera de détecter les fichiers de test en utilisant le chemin de fichier absolu, par conséquent, avoir un dossier avec un nom qui correspond à celui-ci exécutera tous les fichiers comme des tests.

testResultsProcessor [string]​

Par dĂ©faut : undefined

Cette option permet l'utilisation d'un processeur de rĂ©sultats personnalisĂ©. Ce processeur doit ĂȘtre un module de node qui exporte une fonction qui attend un objet avec la structure suivante comme premier argument et le retourne :

{
"success": boolean,
"startTime": epoch,
"numTotalTestSuites": number,
"numPassedTestSuites": number,
"numFailedTestSuites": number,
"numRuntimeErrorTestSuites": number,
"numTotalTests": number,
"numPassedTests": number,
"numFailedTests": number,
"numPendingTests": number,
"numTodoTests": number,
"openHandles": Array<Error>,
"testResults": [{
"numFailingTests": number,
"numPassingTests": number,
"numPendingTests": number,
"testResults": [{
"title": string (message in it block),
"status": "failed" | "pending" | "passed",
"ancestorTitles": [string (message in describe blocks)],
"failureMessages": [string],
"numPassingAsserts": number,
"location": {
"column": number,
"line": number
},
"duration": number | null
},
...
],
"perfStats": {
"start": epoch,
"end": epoch
},
"testFilePath": chemin absolu vers le fichier de test,
"coverage": {}
},
"testExecError:" (existe s'il y a eu un échec de niveau supérieur) {
"message": string
"stack": string
}
...
]
}

testResultsProcessor et reporters sont trÚs similaires l'un à l'autre. Une différence est que le processeur de résultats de test n'est appelé qu'une fois aprÚs que tous les tests soient terminés. Alors qu'un rapporteur a la possibilité de recevoir les résultats des tests aprÚs que les tests individuels et/ou les suites de tests soient terminés.

testRunner [string]​

Par dĂ©faut : jest-circus/runner

Cette option permet d'utiliser un runner de test personnalisĂ©. La valeur par dĂ©faut est jest-circus. Un runner de test personnalisĂ© peut ĂȘtre fourni en spĂ©cifiant un chemin vers une implĂ©mentation d'un runner de test.

Le module de runner de test doit exporter une fonction avec la signature suivante :

function testRunner(
globalConfig: GlobalConfig,
config: ProjectConfig,
environment: Environment,
runtime: Runtime,
testPath: string,
): Promise<TestResult>;

An example of such function can be found in our default jasmine2 test runner package.

testSequencer [string]​

Par dĂ©faut : @jest/test-sequencer

Cette option vous permet d'utiliser un séquenceur personnalisé au lieu de celui par défaut de Jest.

astuce

Les deux sort et shard peuvent Ă©ventuellement retourner une Promise.

Par exemple, vous pouvez trier les chemins de test par ordre alphabĂ©tique :

custom-sequencer.js
const Sequencer = require('@jest/test-sequencer').default;

class CustomSequencer extends Sequencer {
/**
* Select tests for shard requested via --shard=shardIndex/shardCount
* Sharding is applied before sorting
*/
shard(tests, {shardIndex, shardCount}) {
const shardSize = Math.ceil(tests.length / shardCount);
const shardStart = shardSize * (shardIndex - 1);
const shardEnd = shardSize * shardIndex;

return [...tests]
.sort((a, b) => (a.path > b.path ? 1 : -1))
.slice(shardStart, shardEnd);
}

/**
* Sort test to determine order of execution
* Sorting is applied after sharding
*/
sort(tests) {
// Test structure information
// https://github.com/jestjs/jest/blob/6b8b1404a1d9254e7d5d90a8934087a9c9899dab/packages/jest-runner/src/types.ts#L17-L21
const copyTests = [...tests];
return copyTests.sort((testA, testB) => (testA.path > testB.path ? 1 : -1));
}
}

module.exports = CustomSequencer;

Ajouter custom-sequencer Ă  votre configuration Jest :

/** @type {import('jest').Config} */
const config = {
testSequencer: 'path/to/custom-sequencer.js',
};

module.exports = config;

testTimeout [number]​

Par dĂ©faut : 5000

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

transform [object<string, pathToTransformer | [pathToTransformer, object]>]​

Par dĂ©faut : {"\\.[jt]sx?$": "babel-jest"}

Une correspondance entre les expressions rĂ©guliĂšres, les chemins et les transformateurs. De maniĂšre facultative, un tuple avec des options de configuration peut ĂȘtre passĂ© comme deuxiĂšme argument : {filePattern : ['path-to-transformer', {options}]}. Par exemple, voici comment vous pouvez configurer babel-jest pour un comportement diffĂ©rent de celui par dĂ©faut : {'\\.js$': ['babel-jest', {rootMode: 'upward'}]}.

Jest exécute le code de votre projet en tant que JavaScript, donc un transformateur est nécessaire si vous utilisez une syntaxe non supportée par Node hors de la boßte (comme les modÚles JSX, TypeScript, Vue). By default, Jest will use babel-jest transformer, which will load your project's Babel configuration and transform any file matching the /\.[jt]sx?$/ RegExp (in other words, any .js, .jsx, .ts or .tsx file). En outre, babel-jest injectera le plugin Babel nécessaire pour le montage de simulation dont on parle dans Simulation module ES.

Reportez-vous à la section Code Transformation pour plus de détails et des instructions sur la construction de votre propre transformateur.

astuce

Gardez à l'esprit qu'un transformateur n'est exécuté qu'une seule fois par fichier, sauf si le fichier a changé.

N'oubliez pas d'inclure explicitement le transformateur par dĂ©faut babel-jest, si vous souhaitez l'utiliser en parallĂšle avec des prĂ©processeurs de code supplĂ©mentaires :

/** @type {import('jest').Config} */
const config = {
transform: {
'\\.[jt]sx?$': 'babel-jest',
'\\.css$': 'some-css-transformer',
},
};

module.exports = config;

transformIgnorePatterns [array<string>]​

Par dĂ©faut : ["/node_modules/", "\\.pnp\\.[^\\\/]+$"]

Un tableau de chaßnes de patterns regexp qui sont comparées à tous les chemins de fichier source avant transformation. Si le chemin du fichier correspond à un des patterns, il ne sera pas transformé.

Fournir des patterns regexp qui se chevauchent les uns avec les autres peut avoir pour consĂ©quence que les fichiers que vous vous attendiez Ă  ĂȘtre transformĂ©s ne le soient pas. Par exemple :

/** @type {import('jest').Config} */
const config = {
transformIgnorePatterns: ['/node_modules/(?!(foo|bar)/)', '/bar/'],
};

module.exports = config;

Le premier pattern correspondra (et donc ne transformera pas) les fichiers Ă  l'intĂ©rieur de /node_modules Ă  l'exception de ceux de /node_modules/foo/ et /node_modules/bar/. Le second pattern correspondra (et donc ne transformera pas) les fichiers Ă  l'intĂ©rieur d'un chemin avec /bar/ dedans. Avec les deux combinĂ©s, les fichiers dans /node_modules/bar/ ne seront pas transformĂ©s car ils correspondent au second motif, mĂȘme s'ils ont Ă©tĂ© exclus par le premier.

Parfois, il arrive (en particulier dans les projets React Native ou TypeScript) que des modules tiers soient publiés comme du code non transpilés. Comme tous les fichiers à l'intérieur de node_modules ne sont pas transformés par défaut, Jest ne comprendra pas le code de ces modules, ce qui entraßnera des erreurs de syntaxe. Pour surmonter cela, vous pouvez utiliser transformIgnorePatterns pour permettre la transpilation de tels modules. Vous trouverez un bon exemple de ce cas d'utilisation dans le Guide React Native.

Ces chaĂźnes de patterns correspondent au chemin d'accĂšs complet. Utilisez la chaine de caractĂšre <rootDir> pour inclure le chemin vers la racine de votre projet, pour l'empĂȘcher d'ignorer accidentellement tous vos fichiers dans les environnements qui auraient un rĂ©pertoire racine diffĂ©rent.

/** @type {import('jest').Config} */
const config = {
transformIgnorePatterns: [
'<rootDir>/bower_components/',
'<rootDir>/node_modules/',
],
};

module.exports = config;
astuce

If you use pnpm and need to convert some packages under node_modules, you need to note that the packages in this folder (e.g. node_modules/package-a/) have been symlinked to the path under .pnpm (e.g. node_modules/.pnpm/package-a@x.x.x/node_modules/package-a/), so using <rootDir>/node_modules/(?!(package-a|@scope/pkg-b)/) directly will not be recognized, while is to use:

/** @type {import('jest').Config} */
const config = {
transformIgnorePatterns: [
'<rootDir>/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)',
/* if config file is under '~/packages/lib-a/' */
`${path.join(
__dirname,
'../..',
)}/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)`,
/* or using relative pattern to match the second 'node_modules/' in 'node_modules/.pnpm/@scope+pkg-b@x.x.x/node_modules/@scope/pkg-b/' */
'node_modules/(?!.pnpm|package-a|@scope/pkg-b)',
],
};

module.exports = config;

It should be noted that the folder name of pnpm under .pnpm is the package name plus @ and version number, so writing / will not be recognized, but using @ can.

unmockedModulePathPatterns [array<string>]​

Par dĂ©faut : []

Un tableau de chaßnes de patterns regexp qui sont comparées à tous les modules avant que le chargeur de modules ne retourne automatiquement une simulation pour eux. Si le chemin d'un module correspond à l'un des patterns de cette liste, il ne sera pas automatiquement simulé par le chargeur de module.

This is useful for some commonly used 'utility' modules that are almost always used as implementation details almost all the time (like underscore, lodash, etc). C'est généralement une bonne pratique de garder cette liste aussi petite que possible et de toujours utiliser des appels explicites jest.mock()/jest.unmock() dans les tests individuels. La configuration explicite par test est beaucoup plus facile pour les autres lecteurs du test pour comprendre sur quel environnement le test s'exécutera.

Il est possible d'Ă©craser ce paramĂštre par des tests individuels en appelant explicitement jest.mock() en haut du fichier de test.

verbose [boolean]​

Default: false or true if there is only one test file to run

Indique si chaque test individuel doit ĂȘtre reportĂ© pendant l'exĂ©cution. Toutes les erreurs seront Ă©galement affichĂ©es en bas aprĂšs l'exĂ©cution.

watchPathIgnorePatterns [array<string>]​

Par dĂ©faut : []

Un tableau de patterns RegExp qui sont comparés à tous les chemins des fichiers sources avant de réexécuter les tests en mode surveillance (watch). Si le chemin du fichier correspond à l'un des patterns, quand il est mis à jour, il ne déclenchera pas une nouvelle exécution de tests.

Ces patterns correspondent au chemin complet. Utilisez la chaine de caractĂšre <rootDir> pour inclure le chemin vers la racine de votre projet, pour l'empĂȘcher d'ignorer accidentellement tous vos fichiers dans les environnements qui auraient un rĂ©pertoire racine diffĂ©rent. Exemple : ["<rootDir>/node_modules/"].

Even if nothing is specified here, the watcher will ignore changes to the version control folders (.git, .hg, .sl). Les autres fichiers et répertoires cachés, c'est-à-dire ceux qui commencent par un point (.), sont surveillés par défaut. N'oubliez pas d'échapper le point lorsque vous les ajoutez à watchPathIgnorePatterns car il s'agit d'un caractÚre spécial de RegExp.

/** @type {import('jest').Config} */
const config = {
watchPathIgnorePatterns: ['<rootDir>/\\.tmp/', '<rootDir>/bar/'],
};

module.exports = config;

watchPlugins [array<string | [string, Object]>]​

Par dĂ©faut : []

Cette option vous permet d'utiliser des plugins de surveillance personnalisés. Pour en savoir plus sur les plugins de surveillance, naviguez ici.

Les exemples de plugins de surveillance incluent :

info

Les valeurs de la propriété watchPlugins peuvent omettre le préfixe jest-watch- du nom du paquet.

watchman [boolean]​

Par dĂ©faut : true

Utilisation ou non de watchman pour l'exploration des fichiers.

workerIdleMemoryLimit [number|string]​

Par dĂ©faut : undefined

Specifies the memory limit for workers before they are recycled and is primarily a work-around for this issue;

AprĂšs que le worker a exĂ©cutĂ© un test, l'utilisation de la mĂ©moire de celui-ci est vĂ©rifiĂ©e. S'il dĂ©passe la valeur spĂ©cifiĂ©e, le worker est tuĂ© et redĂ©marrĂ©. La limite peut ĂȘtre spĂ©cifiĂ©e de plusieurs façons diffĂ©rentes et quel que soit le rĂ©sultat Math.floor est utilisĂ© pour le transformer en une valeur entiĂšre :

  • <= 1 - La valeur est considĂ©rĂ©e comme un pourcentage de la mĂ©moire systĂšme. Donc 0,5 Ă©tablit la limite de mĂ©moire du worker Ă  la moitiĂ© de la mĂ©moire totale du systĂšme
  • \> 1 - ConsidĂ©rĂ© comme une valeur d'octet fixe. En raison de la rĂšgle prĂ©cĂ©dente, si vous voulez une valeur de 1 octet (je ne sais pas pourquoi), vous pouvez utiliser 1.1.
  • Avec des unitĂ©s
    • 50 - Comme ci-dessus, un pourcentage de la mĂ©moire systĂšme totale
    • 100KB, 65MB, etc - Avec des unitĂ©s pour indiquer une limite de mĂ©moire fixe.
      • K / KB - Kilobytes (x1 000)
      • KiB - Kibibytes (x1 024)
      • M / MB - Megabytes
      • MiB - Mebibytes
      • G / GB - Gigabytes
      • GiB - Gibibytes
attention

Percentage based memory limit does not work on Linux CircleCI workers due to incorrect system memory being reported.

/** @type {import('jest').Config} */
const config = {
workerIdleMemoryLimit: 0.2,
};

module.exports = config;

// [string]​

Cette option permet de commenter dans package.json. Incluez le texte du commentaire comme valeur de cette clĂ© :

package.json
{
"name": "my-project",
"jest": {
"//": "Le commentaire est ici",
"verbose": true
}
}

workerThreads​

Par dĂ©faut : false

Whether to use worker threads for parallelization. Child processes are used by default.

Using worker threads may help to improve performance.

attention

This is experimental feature. Keep in mind that the worker threads use structured clone instead of JSON.stringify() to serialize messages. This means that built-in JavaScript objects as BigInt, Map or Set will get serialized properly. However extra properties set on Error, Map or Set will not be passed on through the serialization step. For more details see the article on structured clone.