Aller au contenu principal
Version : Suivant

Dépannage

Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Oups, un problème ? Utilisez ce guide pour résoudre les soucis avec Jest.

Les tests échouent sans raison apparente​

Essayez le support de débogage intégré à Node. Placez une instruction debugger; dans vos tests, puis exécutez dans votre projet :

node --inspect-brk node_modules/.bin/jest --runInBand [any other arguments here]
or on Windows
node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand [any other arguments here]

Cela exécutera Jest dans un processus Node qu'un débogueur externe peut connecter. Le processus sera en pause jusqu'à la connexion du débogueur.

Pour déboguer dans Chrome (ou tout navigateur Chromium) :

  1. Allez sur chrome://inspect
  2. Cliquez sur "Ouvrir les DevTools dédiés pour Node"
  3. Sélectionnez l'instance Node affichée dans le terminal (ex: localhost:9229)
  4. Déboguez Jest avec les DevTools de Chrome

Les DevTools s'affichent avec un point d'arrêt à la première ligne du CLI Jest (pour vous laisser ouvrir les outils). Cliquez sur le bouton "Play" en haut à droite pour continuer. L'exécution s'arrêtera au debugger où vous pourrez inspecter la portée et la pile d'appels.

note

L'option --runInBand force Jest à exécuter les tests dans le même processus (pas de parallélisation). Essentiel pour le débogage car déboguer plusieurs processus simultanément est complexe.

Débogage dans VS Code​

Plusieurs méthodes existent avec le débogueur intégré de VS Code.

Pour attacher le débogueur :

  1. Lancez vos tests comme précédemment :
node --inspect-brk node_modules/.bin/jest --runInBand [any other arguments here]
or on Windows
node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand [any other arguments here]
  1. Utilisez cette configuration launch.json :
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "attach",
      "name": "Attach",
      "port": 9229
    }
  ]
}

Pour un lancement automatique :

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

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

Pour create-react-app :

{
  "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'infos sur le débogage Node ici.

Débogage dans WebStorm​

WebStorm prend en charge Jest nativement. Lisez Testing With Jest in WebStorm.

Problèmes de cache​

Le script de transformation ou Babel a été modifié mais Jest ne reconnaît pas les changements ?

Réessayez avec --no-cache. Jest met en cache les modules transformés pour accélérer l'exécution. Avec un transformer personnalisé, ajoutez une fonction getCacheKey : exemple dans Relay.

Promesses non résolues​

Si une promesse ne se résout jamais, cette erreur peut survenir :

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

Cause fréquente : conflit entre implémentations de Promesses. Solutions :

  • Remplacer l'implémentation globale : globalThis.Promise = jest.requireActual('promise');
  • Uniformiser les bibliothèques de Promesses

Pour les tests longs, augmentez le timeout avec jest.setTimeout.

jest.setTimeout(10_000); // 10 second timeout

Problèmes avec Watchman​

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

Consultez également le dépannage de Watchman.

Les tests sont extrêmement lents sur Docker et/ou un serveur d'intégration continue (CI)​

Bien que Jest soit généralement très rapide sur des ordinateurs multi-cœurs modernes avec des SSD performants, il peut être lent dans certaines configurations comme l'ont découvert nos utilisateurs.

D'après les conclusions, une solution pour atténuer ce problème et améliorer la vitesse jusqu'à 50% est d'exécuter les tests séquentiellement.

Pour ce faire, vous pouvez exécuter les tests dans le même thread 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 comme Travis-CI est de définir le pool maximum de workers à ~4. Spécifiquement sur Travis-CI, cela peut réduire le temps d'exécution des tests de moitié. Remarque : Le plan gratuit Travis CI disponible pour les projets open source n'inclut que 2 cœurs CPU.

# 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 GitHub Actions, vous pouvez employer github-actions-cpu-cores pour détecter le nombre de CPU et le transmettre à Jest.

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

Vous pouvez également utiliser le flag shard pour paralléliser l'exécution des tests sur plusieurs machines.

coveragePathIgnorePatterns semble ne pas avoir d'effet​

Assurez-vous de ne pas utiliser le plugin babel-plugin-istanbul. Jest encapsule Istanbul et indique donc à Istanbul quels fichiers instrumenter pour la collecte de couverture. Lorsque vous utilisez babel-plugin-istanbul, chaque fichier traité par Babel aura du code de collecte de couverture, il n'est donc pas ignoré par coveragePathIgnorePatterns.

Définition des tests​

Les tests doivent être définis de manière synchrone pour que Jest puisse les collecter.

Pour illustrer cela, imaginez que nous écrivions un test comme ceci :

// Don't do this it will not work
setTimeout(() => {
  it('passes', () => expect(1).toBe(1));
}, 0);

Lorsque Jest exécute votre test pour collecter les test, il n'en trouvera aucun car nous avons programmé la définition de manière asynchrone au prochain tick de la boucle d'événements. Cela signifie que lorsque vous utilisez test.each, vous ne pouvez pas définir la table de manière asynchrone dans un beforeEach / beforeAll.

Toujours non résolu ?​

Consultez la section Aide.