6 étapes pour refactoriser un test Jest
4 septembre 2019
0 minutes de lectureJest 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) :
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 :
C’est pourquoi Jest exige également d’utiliser toHaveProperty() avec expect, comme ceci :
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 ? ?
À 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 :
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 :
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.
