Version : 27.x

Configuration de Jest

La configuration de Jest peut être définie dans le fichier package.json de votre projet, ou à travers un fichier jest.config.js, ou jest.config.ts ou à travers l'option --config <path/to/file.js|ts|cjs|mjs|json>. Si vous souhaitez utiliser votre fichier package.json pour stocker la configuration de Jest, la clé "jest" doit être utilisée tout en haut ainsi Jest saura comment trouver vos paramètres :

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

Ou via JavaScript :

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

module.exports = config;

// Ou fonction asynchrone
module.exports = async () => {
  return {
    verbose: true,
  };
};

Ou via TypeScript (si ts-node est installé) :

jest.config.ts
import type {Config} from '@jest/types';

// Objet synchrone
const config: Config.InitialOptions = {
  verbose: true,
};
export default config;

// Ou fonction asynchrone
export default async (): Promise<Config.InitialOptions> => {
  return {
    verbose: true,
  };
};

Rappelez-vous que la configuration décrite doit pouvoir être sérialisée en JSON.

Lorsque vous utilisez l'option --config , le fichier JSON ne doit pas contenir de clé "jest" :

{
  "bail": 1,
  "verbose": true
}

Options

Ces options vous permettent de contrôler le comportement de Jest dans votre fichier package.json. La philosophie de Jest est de fonctionner parfaitement par défaut, mais parfois vous avez besoin de plus de possibilités de configuration.

Defaults

Vous pouvez récupérer les options par défaut de Jest pour les étendre si nécessaire :

jest.config.js
const {defaults} = require('jest-config');
module.exports = {
  // ...
  moduleFileExtensions: [...defaults.moduleFileExtensions, 'ts', 'tsx'],
  // ...
};

Référence

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: () => {
    return 'token';
  },
  isAuthorized: secret => secret === 'wizard',
};

//__tests__/automocking.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 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.

Exemple :

{
  "collectCoverageFrom": [
    "**/*.{js,jsx}",
    "!**/node_modules/**",
    "!**/vendor/**"
  ]
}

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.

Aide :

Si vous voyez la sortie de couverture ainsi ...

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

remarque

Using v8 is considered experimental. Cela utilise la couverture de code interne de V8 plutôt qu'un code basé sur Babel. Il n'est pas aussi bien testé, et il a également été amélioré dans les dernières versions de Node. Utiliser les dernières versions de node (v14 au moment de cette écriture) donnera de meilleurs résultats.

`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 :

{
  "coverageReporters": ["clover", "json", "lcov", ["text", {"skipFull": true}]]
}

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 :

{
  ...
  "jest": {
    "coverageThreshold": {
      "global": {
        "branches": 80,
        "functions": 80,
        "lines": 80,
        "statements": -10
      }
    }
  }
}

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 :

{
  ...
  "jest": {
    "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
      }
    }
  }
}

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. Voici des exemples de valeurs valides.

module.exports = {
  displayName: 'CLIENT',
};

module.exports = {
  displayName: {
    name: 'CLIENT',
    color: 'blue',
  },
};

Comme option secondaire, 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.

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

attention

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

{
  ...
  "jest": {
    "extensionsToTreatAsEsm": [".ts"]
  }
}

`extraGlobals` [array<string>]

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

{
  ...
  "jest": {
    "extraGlobals": ["Math"]
  }
}

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

{
  ...
  "jest": {
    "forceCoverageMatch": ["**/*.t.js"]
  }
}

`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 :

{
  ...
  "jest": {
    "globals": {
      "__DEV__": true
    }
  }
}

info

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 d'utiliser un module de configuration globale personnalisé qui exporte une fonction asynchrone qui est déclenchée une fois avant toutes les suites de test. This function gets Jest's globalConfig object as a parameter.

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
// peut être synchronisé
module.exports = async () => {
  // ...
  // Définit la référence à mongod afin de fermer le serveur pendant le nettoyage.
  global.__MONGOD__ = mongod;
};

teardown.js
module.exports = async function () {
  await global.__MONGOD__.stop();
};

`globalTeardown` [string]

Par défaut : undefined

Cette option permet l'utilisation d'un module de nettoyage global personnalisé qui exporte une fonction asynchrone qui est déclenchée une fois après toutes les suites de tests. This function gets Jest's globalConfig object as a parameter.

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>;
  /** S'il faut lancer une erreur en cas de collision de module. */
  throwOnModuleCollision?: boolean;
  /** Module HasteMap personnalisé */
  hasteMapModulePath?: string;
};

`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 : "maxWorkers" : "50%"

`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 : ["node_modules", "bower_components"]

`moduleFileExtensions` [array<string>]

Par défaut : ["js", "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.

Exemple :

{
  "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"
    ]
  }
}

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.

`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. Exemple : ["<rootDir>/app/"].

`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
Yarn
pnpm

npm install --save-dev node-notifier

yarn add --dev node-notifier

pnpm add --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.

`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 :

{
  "preset": "foo-bar"
}

Les presets peuvent également être relatifs aux chemins du système de fichiers.

{
  "preset": "./node_modules/foo-bar/jest-preset.js"
}

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.

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

{
  "projects": ["<rootDir>", "<rootDir>/examples/*"]
}

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 :

{
  "projects": [
    {
      "displayName": "test"
    },
    {
      "displayName": "lint",
      "runner": "jest-runner-eslint",
      "testMatch": ["<rootDir>/**/*.js"]
    }
  ]
}

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.

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

Par défaut : undefined

Utilisez cette option de configuration pour ajouter des rapporteurs personnalisés à Jest. Un rapporteur personnalisé est une classe qui implémente les méthodes onRunStart, onTestStart, onTestResult, onRunComplete qui seront appelées lorsqu'un de ces événements se produira.

Si des rapporteurs personnalisés sont spécifiés, les rapporteurs par défaut de Jest seront écrasés. Pour conserver les rapporteurs par défaut, default peut être passé comme nom de module.

Ceci remplacera les rapporteurs par défaut :

{
  "reporters": ["<rootDir>/my-custom-reporter.js"]
}

Ceci utilisera le rapporteur personnalisé en plus des rapporteurs par défaut que Jest fournit :

{
  "reporters": ["default", "<rootDir>/my-custom-reporter.js"]
}

En outre, les rapporteurs personnalisés peuvent être configurés en passant un objet options comme deuxième argument :

{
  "reporters": [
    "default",
    ["<rootDir>/my-custom-reporter.js", {"banana": "yes", "pineapple": "no"}]
  ]
}

Custom reporter modules must define a class that takes a globalConfig and reporter options as constructor arguments:

Exemple de rapporteur :

my-custom-reporter.js
class MyCustomReporter {
  constructor(globalConfig, options) {
    this._globalConfig = globalConfig;
    this._options = options;
  }

  onRunComplete(contexts, results) {
    console.log('Sortie du reporter personnalisé:');
    console.log('GlobalConfig: ', this._globalConfig);
    console.log('Options: ', this._options);
  }
}

module.exports = MyCustomReporter;
// ou export default MyCustomReporter;

Les rapporteurs personnalisés peuvent également forcer Jest à sortir avec un code différent de 0 en renvoyant une erreur depuis les méthodes getLastError()

class MyCustomReporter {
  // ...
  getLastError() {
    if (this._shouldFail) {
      return new Error('my-custom-reporter.js a reporté une erreur');
    }
  }
}

For the full list of methods and argument types see 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 de node qui exporte une fonction qui attend une chaîne de caractères comme premier argument pour le chemin à résoudre et un objet avec la structure suivante comme second argument :

{
  "basedir": string,
  "conditions": [string],
  "defaultResolver": "function(request, options)",
  "extensions": [string],
  "moduleDirectory": [string],
  "paths": [string],
  "packageFilter": "function(pkg, pkgdir)",
  "pathFilter": "function(pkg, path, relativePath)",
  "rootDir": [string]
}

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.

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 personnalisé, par exemple (request, options).

Par exemple, si vous voulez respecter le champ "browser" de Browserify, vous pouvez utiliser la configuration suivante :

{
  ...
  "jest": {
    "resolver": "<rootDir>/resolver.js"
  }
}

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

module.exports = browserResolve.sync;

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" :

{
  ...
  "jest": {
    "resolver": "my-module-resolve"
  }
}

// my-module-resolve package

module.exports = (request, options) => {
  // Apelle defaultResolver, ainsi nous utilisons son cache, sa gestion d'erreur, etc.
  return options.defaultResolver(request, {
    ...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,
      };
    },
  });
};

Actuellement, Jest ne supporte que le sous-chemin "main" (.) du paquet exports. Cependant, comme Jest fournit conditions en tant qu'option lors de l'appel de résolveurs personnalisés, la prise en charge complète des exports peut être implémentée dans l'espace utilisateur. Jest passera ['import', 'default'] lorsque vous exécutez un test en mode ESM, et ['require', 'default'] lorsque vous exécutez avec CJS. De plus, les environnements de test personnalisés peuvent spécifier une méthode exportConditions qui retourne un tableau de conditions qui seront passées avec les valeurs par défaut de Jest.

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

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

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

In other words, setupFilesAfterEnv modules are meant for code which is repeating in each test files. 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();
});

module.exports = {
  setupFilesAfterEnv: ['<rootDir>/setup-jest.js'],
};

`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 : undefined

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" :

{
  "jest": {
    "snapshotFormat": {
      "printBasicPrototype": false
    }
  }
}

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

test('ne montre pas de prototypes pour l\'objet et le tableau en ligne', () => {
  const object = {
    array: [{hello: 'Danger'}],
  };
  expect(object).toMatchInlineSnapshot(`
{
  "array": [
    {
      "hello": "Danger",
    },
  ],
}
    `);
});

`snapshotResolver` [string]

Par défaut : undefined

Le chemin vers un module qui peut résoudre le test<->chemin du snapshot. Cette option de configuration vous permet de personnaliser l'endroit où Jest stocke les fichiers snapshot sur le disque.

Exemple de module résolveur de snapshot :

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.

Exemple de module de sérialisation :

// my-serializer-module
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.

Pour utiliser my-serializer-module comme sérialiseur, la configuration serait la suivante :

{
  ...
  "jest": {
    "snapshotSerializers": ["my-serializer-module"]
  }
}

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 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');

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

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

    // Se déclenchera si docblock contient @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 = global.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:

module.exports = {
  testEnvironment: 'jsdom',
  testEnvironmentOptions: {
    html: '<html lang="zh-cmn-Hant"></html>',
    userAgent: 'Agent/007',
  },
};

`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é.

`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
      }
    },
    ...
    ],
    "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. sort peut éventuellement retourner une Promesse.

Exemple :

Trie le chemin de test par ordre alphabétique.

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

class CustomSequencer extends Sequencer {
  sort(tests) {
    // Test structure information
    // https://github.com/jestjs/jest/blob/6b8b1404a1d9254e7d5d90a8934087a9c9899dab/packages/jest-runner/src/types.ts#L17-L21
    const copyTests = Array.from(tests);
    return copyTests.sort((testA, testB) => (testA.path > testB.path ? 1 : -1));
  }
}

module.exports = CustomSequencer;

Utilisez-le dans votre fichier de configuration Jest comme ceci :

{
  "testSequencer": "path/to/testSequencer.js"
}

`testTimeout` [number]

Par défaut : 5000

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

`testURL` [string]

Par défaut : http://localhost

Cette option définit l'URL pour l'environnement jsdom . Elle se retrouve dans des propriétés telles que location.href.

`timers` [string]

Par défaut : real

La définition de cette valeur à fake ou modern active par défaut les temporisateurs simulés pour tous les tests. Les faux temporisateurs sont utiles lorsqu'un morceau de code définit un long délai d'attente que nous ne voulons pas attendre dans un test. Vous pouvez en apprendre plus sur les temporisateurs simulées ici.

Si la valeur est legacy, l'ancienne implémentation sera utilisée comme implémentation au lieu de celle soutenue par @sinonjs/fake-timers.

`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. Un transformateur est un module qui fournit une fonction synchrone pour transformer les fichiers source. Par exemple, si vous voulez être en mesure d'utiliser une nouvelle fonctionnalité du langage dans vos modules ou tests qui ne sont pas encore pris en charge par node, vous pouvez brancher l'un des nombreux compilateurs qui compilent une future version de JavaScript en une version actuelle. Example: see the examples/typescript example or the webpack tutorial.

Les exemples de ces compilateurs incluent :

Babel
TypeScript
Pour construire votre propre transformateur, veuillez visiter la section Transformateur personnalisé

Vous pouvez passer la configuration à un transformateur ainsi {filePattern: ['path-to-transformer', {options}]}. Par exemple, pour configurer babel-jest pour un comportement différent de celui par défaut, {"\\.js$": ['babel-jest', {rootMode: "upward"}]}

astuce

A transformer is only run once per file unless the file has changed. Lors du développement d'un transformateur, il peut être utile d'exécuter Jest avec --no-cache pour supprimer fréquemment le cache de Jest.

remarque

When adding additional code transformers, this will overwrite the default config and babel-jest is no longer automatically loaded. Si vous voulez l'utiliser pour compiler JavaScript ou Typescript, il faut le définir explicitement en ajoutant {"\\.[jt]sx?$": "babel-jest"} à la propriété transform. See babel-jest plugin.

Un transformateur doit être un objet avec au moins une fonction process , et il est également recommandé d'inclure une fonction getCacheKey. Si votre transformateur est écrit en ESM, vous devriez avoir un export par défaut avec cet objet.

Si les tests sont écrits en utilisant ESM natif le transformateur peut exporter processAsync et getCacheKeyAsync à la place ou en plus des variantes synchrones.

`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 :

{
  "transformIgnorePatterns": ["/node_modules/(?!(foo|bar)/)", "/bar/"]
}

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.

Exemple :

{
  "transformIgnorePatterns": [
    "<rootDir>/bower_components/",
    "<rootDir>/node_modules/"
  ]
}

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:

{
  "transformIgnorePatterns": [
    "<rootDir>/node_modules/.pnpm/(?!(package-a|@scope\\+pkg-b)@)"
  ]
}

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.

Also note that you need using '`${path.join(__dirname, '../..')}/node_modules/.pnpm/...`' instead of <rootDir>/node_modules/.pnpm/... when the config file is under ~/packages/lib-a/, or using relative pattern node_modules/(?!.pnpm|package-a|@scope/pkg-b) to match the second 'node_modules/' in 'node_modules/.pnpm/@scope+pkg-b@xxx/node_modules/@scope/pkg-b/'

`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/"].

Même si rien n'est spécifié ici, la surveillance ignorera les changements dans les dossiers de contrôle de version (.git, .hg). 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.

Exemple :

{
  "watchPathIgnorePatterns": ["<rootDir>/\\.tmp/", "<rootDir>/bar/"]
}

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

`//` [string]

Aucun par défaut

Cette option permet de commenter dans package.json. Incluez le texte du commentaire comme valeur de cette clé n'importe où dans package.json.

Exemple :

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

Options
- Defaults
Référence

Options​

Defaults​

Référence​

automock [boolean]​

bail [number | boolean]​

cacheDirectory [string]​

clearMocks [boolean]​

collectCoverage [boolean]​

collectCoverageFrom [array]​

coverageDirectory [string]​

coveragePathIgnorePatterns [array<string>]​

coverageProvider [string]​

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

coverageThreshold [object]​

dependencyExtractor [string]​

displayName [string, object]​

errorOnDeprecated [boolean]​

extensionsToTreatAsEsm [array<string>]​

extraGlobals [array<string>]​

forceCoverageMatch [array<string>]​

globals [object]​

globalSetup [string]​

globalTeardown [string]​

haste [object]​

injectGlobals [boolean]​

maxConcurrency [number]​

maxWorkers [number | string]​

moduleDirectories [array<string>]​

moduleFileExtensions [array<string>]​

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

modulePathIgnorePatterns [array<string>]​

modulePaths [array<string>]​

notify [boolean]​

notifyMode [string]​

Modes​

preset [string]​

prettierPath [string]​

projects [array<string | ProjectConfig>]​

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

resetMocks [boolean]​

resetModules [boolean]​

resolver [string]​

restoreMocks [boolean]​

rootDir [string]​

roots [array<string>]​

runner [string]​

setupFiles [array]​

setupFilesAfterEnv [array]​

slowTestThreshold [number]​

snapshotFormat [object]​

snapshotResolver [string]​

snapshotSerializers [array<string>]​

testEnvironment [string]​

testEnvironmentOptions [Object]​

testFailureExitCode [number]​

testMatch [array<string>]​

testPathIgnorePatterns [array<string>]​

testRegex [string | array<string>]​

testResultsProcessor [string]​

testRunner [string]​

testSequencer [string]​

testTimeout [number]​

testURL [string]​

timers [string]​

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

transformIgnorePatterns [array<string>]​

unmockedModulePathPatterns [array<string>]​

verbose [boolean]​

watchPathIgnorePatterns [array<string>]​

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

watchman [boolean]​

// [string]​

Options

Defaults

Référence

`automock` [boolean]

`bail` [number | boolean]

`cacheDirectory` [string]

`clearMocks` [boolean]

`collectCoverage` [boolean]

`collectCoverageFrom` [array]

`coverageDirectory` [string]

`coveragePathIgnorePatterns` [array<string>]

`coverageProvider` [string]

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

`coverageThreshold` [object]

`dependencyExtractor` [string]

`displayName` [string, object]

`errorOnDeprecated` [boolean]

`extensionsToTreatAsEsm` [array<string>]

`extraGlobals` [array<string>]

`forceCoverageMatch` [array<string>]

`globals` [object]

`globalSetup` [string]

`globalTeardown` [string]

`haste` [object]

`injectGlobals` [boolean]

`maxConcurrency` [number]

`maxWorkers` [number | string]

`moduleDirectories` [array<string>]

`moduleFileExtensions` [array<string>]

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

`modulePathIgnorePatterns` [array<string>]

`modulePaths` [array<string>]

`notify` [boolean]

`notifyMode` [string]

Modes

`preset` [string]

`prettierPath` [string]

`projects` [array<string | ProjectConfig>]

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

`resetMocks` [boolean]

`resetModules` [boolean]

`resolver` [string]

`restoreMocks` [boolean]

`rootDir` [string]

`roots` [array<string>]

`runner` [string]

`setupFiles` [array]

`setupFilesAfterEnv` [array]

`slowTestThreshold` [number]

`snapshotFormat` [object]

`snapshotResolver` [string]

`snapshotSerializers` [array<string>]

`testEnvironment` [string]

`testEnvironmentOptions` [Object]

`testFailureExitCode` [number]

`testMatch` [array<string>]

`testPathIgnorePatterns` [array<string>]

`testRegex` [string | array<string>]

`testResultsProcessor` [string]

`testRunner` [string]

`testSequencer` [string]

`testTimeout` [number]

`testURL` [string]

`timers` [string]

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

`transformIgnorePatterns` [array<string>]

`unmockedModulePathPatterns` [array<string>]

`verbose` [boolean]

`watchPathIgnorePatterns` [array<string>]

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

`watchman` [boolean]

`//` [string]