6 étapes pour refactoriser un test Jest

Écrit par

4 septembre 2019

0 minutes de lecture

Jest propose une fonctionnalité méconnue qui permet de personnaliser la gestion des erreurs d’assertion affichées dans la console en cas d’échec des tests. Imaginons le code de test suivant, qui doit parcourir un objet par programmation pour vérifier que les clés attendues existent (à l’aide de la fonction expect) :

Éditeur de code sombre affichant un test Jest qui vérifie que les fichiers JavaScript ont les classes d’application correspondantes.

Le test est bien écrit. Imaginons maintenant qu’un membre de l’équipe apporte des modifications au code : il ajoute un nouveau fichier à un endroit, mais oublie de l’ajouter ailleurs, dans une partie importante du même projet, par exemple là où il faut s’assurer que le fichier est correctement exporté.

Lors de la prochaine exécution du test, celui-ci échouera. Pourtant, la raison ne sera pas évidente pour la plupart des gens ; et si vous découvrez le code, vous ne saurez probablement même pas ce qui a échoué. Essayez :

Éditeur de code sombre affichant l’échec d’un test Jest : validators doivent être exportés, avec Received: undefined et une erreur d’assertion à la ligne 13.

C’est pourquoi Jest exige également d’utiliser toHaveProperty() avec expect, comme ceci :

Éditeur de code en thème sombre affichant du JavaScript qui extrait un nom de classe de chaque nom de fichier et teste la propriété attendue.

Désormais, en cas d’échec d’un test, il est au moins plus facile de repérer la propriété manquante. Mais le résultat reste assez obscur, comme le montre la capture d’écran suivante. Que peut-on faire ? ?

Éditeur de code sombre affichant l’échec d’un test Jest indiquant que toutes les classes de validation doivent être exportées depuis index.js.

À ce stade, les annotations déjà présentes pourraient suffire. Comme vous pouvez le constater, le nom du test est explicite. Mais un seul cas de test échoue, et lorsqu’on examine la trace du test, il est difficile de déterminer clairement quels validateurs ont été utilisés.

Refactorisons le code :

Éditeur de code au thème sombre affichant des tests Jest qui vérifient que les classes de validation sont exportées depuis index.js

Désormais, que mon test réussisse ou échoue, il est beaucoup plus évident et intuitif de comprendre ce qui a été testé, ce qui a échoué et pourquoi :

Sortie du terminal montrant la réussite des tests Jest des validateurs dans app.test.js, notamment ValidateHost.js et ValidateHttps.js.

C’est bien mieux ! ???

Si vous aimez Jest autant que moi (?) , vous pourriez aussi être intéressé par quelques-uns de mes autres articles sur Jest :

Si la sécurité web vous intéresse également, j’aimerais vous retrouver dans la communauté Slack de The Secure Developer, ou sur Twitter si vous préférez.