Aller au contenu principal
Version : 29.4

Dépannage

Oh oh, quelque chose s'est mal passé ? Utilisez ce guide pour résoudre les problèmes avec Jest.

Les tests échouent et vous ne savez pourquoi

Try using the debugging support built into Node. Placez l'instruction debugger; dans l’un de vos tests et puis, dans le répertoire de votre projet, exécutez :

node --inspect-brk node_modules/.bin/jest --runInBand [tout autre argument ici]
ou sous Windows
node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand [tout autre argument ici]

Cela exécutera Jest dans un processus de Node auquel un débogueur externe peut se connecter. Notez que le processus sera mis en pause jusqu'à ce que le débogueur s'y soit connecté.

Pour déboguer dans Google Chrome (ou n'importe quel navigateur basé sur Chromium), ouvrez votre navigateur et allez dans chrome://inspect et cliquez sur « Open Dedicated DevTools for Node », qui vous donnera une liste d'instances de node disponibles auxquelles vous pouvez vous connecter. Cliquez sur l'adresse affichée dans le terminal (généralement quelque chose comme localhost:9229) après avoir exécuté la commande ci-dessus, et vous serez en mesure de déboguer Jest en utilisant DevTools de Chrome.

Les outils de développement Chrome seront affichés, et un point d'arrêt sera défini à la première ligne du script CLI de Jest (ceci est fait pour vous donner le temps d'ouvrir les outils de développement et pour empêcher Jest de s'exécuter avant que vous ayez le temps de le faire). Cliquez sur le bouton qui ressemble à un bouton « play » en haut à droite de l'écran pour continuer l'exécution. Lorsque Jest exécute le test qui contient l'instruction debugger , l'exécution se met en pause et vous pouvez examiner la portée actuelle et la pile d'appels.

remarque

The --runInBand cli option makes sure Jest runs the test in the same process rather than spawning processes for individual tests. Normalement, Jest parallélise les tests à travers les processus, mais il est difficile de déboguer plusieurs processus en même temps.

Débogage dans VS Code

Il y a plusieurs façons de déboguer les tests Jest avec le débogueur intégré de Visual Studio Code.

Pour attacher le débogueur intégré, exécutez vos tests comme mentionné précédemment :

node --inspect-brk node_modules/.bin/jest --runInBand [tout autre argument ici]
ou sous Windows
node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand [tout autre argument ici]

Rattachez ensuite le débogueur de VS Code en utilisant la configuration launch.json suivante :

{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "attach",
"name": "Attach",
"port": 9229
}
]
}

Pour lancer et rattacher automatiquement un processus exécutant vos tests, utilisez la configuration suivante :

{
"version": "0.2.0",
"configurations": [
{
"name": "Debug Jest Tests",
"type": "node",
"request": "launch",
"runtimeArgs": [
"--inspect-brk",
"${workspaceRoot}/node_modules/.bin/jest",
"--runInBand"
],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen"
}
]
}

ou ce qui suit pour Windows :

{
"version": "0.2.0",
"configurations": [
{
"name": "Debug Jest Tests",
"type": "node",
"request": "launch",
"runtimeArgs": [
"--inspect-brk",
"${workspaceRoot}/node_modules/jest/bin/jest.js",
"--runInBand"
],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen"
}
]
}

Si vous utilisez l'application create-react-app de Facebook, vous pouvez déboguer vos tests Jest avec la configuration suivante :

{
"version": "0.2.0",
"configurations": [
{
"name": "Debug CRA Tests",
"type": "node",
"request": "launch",
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/react-scripts",
"args": [
"test",
"--runInBand",
"--no-cache",
"--env=jsdom",
"--watchAll=false"
],
"cwd": "${workspaceRoot}",
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen"
}
]
}

Plus d'informations sur le débogage de Node peuvent être trouvées ici.

Débogage dans WebStorm

WebStorm a un support intégré pour Jest. Lisez Tester avec Jest dans WebStorm pour en savoir plus.

Problèmes de Cache

Le script de transformation a été modifié ou Babel a été mis à jour et les changements ne sont pas reconnus par Jest ?

Réessayez avec --no-cache. Jest met en cache les fichiers de modules transformés pour accélérer l'exécution des tests. Si vous utilisez votre propre transformateur personnalisé, pensez à ajouter une fonction getCacheKey à celle-ci : getCacheKey dans Relay.

Promesses non résolues

Si une promesse n'est pas résolue du tout, cette erreur peut être levée :

- Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.`

Le plus souvent, ce problème est causé par des implémentations conflictuelles de promesses. Envisagez de remplacer l'implémentation de la promesse globale par la vôtre, par exemple globalThis.Promise = jest.requireActual('promise'); et/ou consolidez les bibliothèques de promesses utilisées en une seule.

Si votre test s'exécute de manière prolongée, vous pouvez envisager d'augmenter le délai d'attente en appelant jest.setTimeout

jest.setTimeout(10000); // timeout de 10 secondes

Problèmes de Watchman

Essayez d'exécuter Jest avec --no-watchman ou définissez l'option de configuration watchman à false.

Consulter aussi dépannage de watchman.

Les tests sont extrêmement lents sur le serveur Docker et/ou l'intégration continue (CI).

While Jest is most of the time extremely fast on modern multi-core computers with fast SSDs, it may be slow on certain setups as our users have discovered.

Based on the findings, one way to mitigate this issue and improve the speed by up to 50% is to run tests sequentially.

Pour ce faire, vous pouvez exécuter les tests dans le même processus en utilisant --runInBand :

# Using Jest CLI
jest --runInBand

# Using your package manager's `test` script (e.g. with create-react-app)
npm test -- --runInBand

Une autre alternative pour accélérer le temps d'exécution des tests sur les serveurs d'intégration continue tels que Travis-CI est de définir le nombre maximal de workers à ~4. En particulier sur Travis-CI, cela peut réduire de moitié le temps d'exécution des tests. Remarque : le forfait gratuit de Travis CI disponible pour les projets open source ne comprend que 2 cœurs de processeur.

# Using Jest CLI
jest --maxWorkers=4

# Using your package manager's `test` script (e.g. with create-react-app)
npm test -- --maxWorkers=4

Si vous utilisez des actions GitHub, vous pouvez utiliser github-actions-cpu-cores pour détecter le nombre de processeurs, et le passer à Jest.

- name: Get number of CPU cores
id: cpu-cores
uses: SimenB/github-actions-cpu-cores@v1
- name: run tests
run: yarn jest --max-workers ${{ steps.cpu-cores.outputs.count }}

Une autre chose que vous pouvez faire est d'utiliser l'option shard pour paralléliser l'exécution de test sur plusieurs machines.

coveragePathIgnorePatterns ne semble avoir aucun effet.

Assurez-vous que vous n'utilisez pas le plugin babel-plugin-istanbul. Jest enveloppe Istanbul, et indique donc également à Istanbul quels fichiers doivent être traités avec la collection de couverture. Lors de l'utilisation de babel-plugin-istanbul, chaque fichier qui est traité par Babel aura un code de collecte de couverture, donc il ne sera pas ignoré par coveragePathIgnorePatterns.

Définition des tests

Les tests doivent être définis de manière synchronisée pour que Jest puisse collecter vos tests.

Comme exemple pour montrer pourquoi c'est le cas, imaginez que nous avons écrit un tel test :

// Ne le faites pas, cela ne fonctionnera pas
setTimeout(() => {
it('passes', () => expect(1).toBe(1));
}, 0);

Lorsque Jest exécute votre test pour collecter les tests, il n'en trouvera aucun car nous avons configuré la définition pour qu'elle se produise de manière asynchrone au prochain déclenchement de la boucle d'événement. This means when you are using test.each you cannot set the table asynchronously within a beforeEach / beforeAll.

Toujours pas de solution ?

Consultez l'aide.