Problèmes de test avec Jest et ESM et comment les résoudre

Cette semaine, j'ai été chargé d'ajouter des tests à mon projet RefactorCode. Au fur et à mesure que je commençais à ajouter de nouvelles fonctionnalités, j'ai remarqué que certaines fonctionnalités existantes ne fonctionnaient plus et il devenait de plus en plus difficile de tout tester manuellement. Cela a clairement montré que je devais mettre en œuvre des tests automatisés appropriés pour garantir la stabilité de l'application.

Comme j'avais une expérience préalable avec Jest lors de mon précédent cours Cloud Computing pour programmeurs, où j'ai travaillé avec Node.js, j'ai décidé de l'utiliser également pour ce projet. J'ai commencé par écrire quelques tests pour vérifier la fonctionnalité de mon code. Cependant, j’ai rencontré quelques erreurs auxquelles je n’avais jamais été confronté auparavant. Après quelques débogages et recherches dans Stack Overflow, j'ai réalisé que des configurations supplémentaires étaient requises lors de l'utilisation d'ESM (modules ECMAScript) avec Jest. Dans mon précédent projet, j'avais utilisé CommonJS, qui fonctionnait parfaitement. Alors que j'aurais pu choisir d'utiliser Babel pour la conversion, Jest a proposé une nouvelle fonctionnalité bêta qui permettait à ESM de s'exécuter directement. J'ai décidé de l'essayer et cela a très bien fonctionné !

Ceci explique tout ce qui concerne la configuration de jest avec ESM : https://jestjs.io/docs/ecmascript-modules

Voici un aperçu rapide de la configuration :

Installer Jest :

npm install --save-dev jest

Créez un fichier jest.config.js. Ici, je définis également les dossiers à ignorer :

export default {
  testPathIgnorePatterns: ["/node_modules/", "/examples"],
  transform: {},
};

Dans la section des scripts package.json, utilisez l'argument expérimental pour que jest fonctionne avec les modules ESM :

"scripts": {
    "test": "node --experimental-vm-modules node_modules/jest/bin/jest.js"
}

Créez un fichier de test. J'ai créé tous les tests dans un dossier de test dans le répertoire racine. En voici un simple que j'ai créé :

import { readFile, checkIfDirectory } from "../src/fileUtils";

describe("File Utility", () => {
    test("Read File", () => {
      readFile("./examples/test.txt").then((data) => {
        expect(data).toBe("Hello World");
      });

    });

    test('should return true if the path is a directory', async () => {
      const result = await checkIfDirectory('./examples');
      expect(result).toBe(true);
    });
});

Si vous souhaitez tester en utilisant un seul fichier de test :

npm test -- banner.test.js

Pour exécuter tous les tests, nous utilisons le script que nous avons ajouté plus tôt dans package.json :

npm run test

Enfin, les tests de base ont été mis en place. Cependant, ce n’était que le début de mon parcours de dépannage. J'ai également rencontré des difficultés avec les bibliothèques et les modules moqueurs, d'autant plus qu'ils utilisaient ESM. Ceux-ci nécessitaient une configuration supplémentaire, mais après quelques ajustements, j'ai pu tout faire fonctionner et les tests se sont déroulés avec succès.

Au lieu d'utiliser le jest.mock habituel, vous devez utiliser jest.unstable_mockModule :

For example: await jest.unstable_mockModule("fs", () => ({
  existsSync: jest.fn(),
  readFileSync: jest.fn(),
}));

Voir cette section pour plus d'informations.

L'une des fonctionnalités principales que je voulais tester impliquait l'intégration avec l'API Gemini. Comme je ne voulais pas compter sur l'API en direct pour les tests, j'ai décidé de me moquer des appels d'API. Au départ, j'ai essayé d'utiliser Nock, mais j'ai rencontré des problèmes car cela ne fonctionnait pas bien avec l'implémentation de récupération par défaut de Node. Il semblait que la bibliothèque Gemini utilisait la récupération par défaut au lieu d'une implémentation de récupération tierce, ce qui provoquait l'échec de la simulation. Après plusieurs tentatives sans succès, je suis passé à une autre bibliothèque appelée MSW (Mock Service Worker). Bien que la création d’un serveur fictif ait nécessité un peu plus de configuration, cela a parfaitement fonctionné du premier coup. J'ai élaboré un exemple de réponse basé sur la réponse de l'API Gemini, ce qui m'a permis de tester la fonctionnalité refactorisée.

Voici comment le serveur fictif a été configuré pour référence :

npm install --save-dev jest

Vous pouvez voir que je me moque d'un point de terminaison d'API spécifique que j'utilise pour l'application. Il ne vous reste plus qu'à ajouter ce qui suit pour démarrer le serveur pendant les tests :

export default {
  testPathIgnorePatterns: ["/node_modules/", "/examples"],
  transform: {},
};

En réfléchissant au processus, ce fut une excellente expérience d'apprentissage pour moi. Avec le recul, j'aurais probablement dû vérifier la compatibilité des bibliothèques que j'utilisais et envisager au préalable tout problème potentiel. Malgré les défis, je suis heureux d’avoir atteint un point où mes tests se déroulent sans problème. J'ai hâte d'ajouter plus de tests à l'avenir et d'améliorer la stabilité globale de mon projet.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!