Comment corriger un bug front ?
Ou comment être convaincu par le TDD et comprendre l’intérêt des tests d’intégration en corrigeant un bug.
Récemment, j’ai eu à corriger un bug sur un projet déployé en recette. Bug très facile à reproduire, environnement et technos maîtrisés, je me suis dit que ce serait l’occasion parfaite pour faire du TDD. J’ai eu envie de vous raconter cette expérience dans cet article à travers un exemple très simple qui illustre parfaitement l’intérêt des tests d’intégration et le fait de les écrire avant le développement.
Contexte du bug à corriger
Pour replacer le contexte, voici quelques captures d’écran du composant en question. Il est assez simple. Son objectif est d’afficher un tableau d’activités provenant d’une API.
Chacune de ces activités ainsi affichées, lorsqu’elle est dans un état “complété”, peut être ajoutée à une liste afin de les publier par la suite.
Lorsqu’une activité est dans la liste des activités à publier, elle peut être supprimée de cette liste. Le bug se trouvait sur cette fonctionnalité. En effet, lorsque l’utilisateur supprimait une seule activité, toute la liste était vidée.
Evidemment, le comportement attendu n’était pas celui-là. Il fallait pouvoir supprimer une seule activité à la fois de cette liste :
Correction du bug
Commençons par les choses qui fâchent, tous mes tests étaient au vert, et la couverture de code était à 100%.
Naïvement, j’aurais pu foncer tête baissée sur le code qui s’exécute au click sur le bouton “Supprimer des activités à publier”. Le scénario aurait été classique. Soit l’erreur était évidente, je l’aurais corrigée plus ou moins rapidement (peut-être même à base de console.log …) et j’aurais vérifié le coverage. En effet, dans notre équipe nous souhaitons 100% de couverture sur nos projets. La valeur n’aurait sûrement pas changé. Dans ce cas je n’étais théoriquement même pas obligé d’écrire un test … Soit l’erreur était plus complexe, et je serais tombé dans quelque chose qui nous est déjà tous arrivés, passer une demi-journée ou plus à corriger un problème en apparence simple, en s’enlisant dans des tentatives de correction, en faisant des refacto, et en créant potentiellement des bugs ailleurs …
Comme je le disais plus tôt, la fonctionnalité qui posait problème était pourtant bien couverte par un test d’intégration :
En lisant le test, on trouve rapidement le problème. Il vérifie seulement l’interaction avec un seul élément. D’où la couverture à 100% et aucun test rouge. Ce test a vraisemblablement été écrit après le développement de la fonctionnalité afin de la sécuriser (et de faire monter le coverage ?…). En les écrivant avant le développement, ils auraient pu répondre à des besoins fonctionnels précis tels que :
- Je veux ajouter une activité à publier
- Je veux ajouter plusieurs activités à publier
- Je veux supprimer une activité à publier lorsqu’il y en a une seule de sélectionnée
- Je veux supprimer une activité à publier lorsqu’il y en a plusieurs de sélectionnées
- …
Caractérisation du bug
La pratique du TDD, c’est-à-dire écrire les tests avant de développer la fonctionnalité, est connue de tous, appréciée par la plupart mais appliquée seulement par quelques-uns. Cette pratique peut parfois être compliquée à mettre en place. En effet, en mode exploratoire, aussi bien lorsque le besoin n’est pas clair que lorsque la technologie utilisée n’est pas maîtrisée, il est quasi impossible d’écrire les tests avant. Dans ces cas-là, la fonctionnalité sera développée, puis un test sera écrit, puis une refacto sera faite.
Ici, ce n’est pas le cas. Tous les voyants sont aux verts. Le besoin est parfaitement clair car exprimé à travers un bug, et la technologie est maîtrisée car déjà en place. Aucune raison de ne pas faire de TDD !
Dans ce cas, l’idée est de reproduire le bug à travers un test :
Ce test reproduit dans l’ordre les actions faites pour atteindre ce bug :
- Montage du composant
- Ajout de deux activités dans la liste des activités à publier (récupération de la liste des boutons d’ajout puis clique sur les deux premiers)
- Suppression d’une activité à publier (récupération de la liste des boutons de suppression puis clique sur le premier)
- Vérification que le bouton de validation de la publication affiche bien “Publier l’activité”, c’est-à-dire qu’il reste bien une seule activité dans la liste des activités à publier.
Comme en TDD, ce test est passé au rouge dès la fin de son écriture. A ce moment-là, un vrai sentiment de sécurité est survenu. Je n’avais même plus besoin de lancer mon navigateur pour vérifier que le bug était bien corrigé.
Et la correction dans tout ça ?
Au final, la correction était très simple et due à une erreur d’inattention.
En effet, la liste des activités à publier est gérée à travers un tableau mais manipulée grâce à des sets. Malheureusement, les méthodes de manipulation de Set en Javascript mutent l’objet. Dans ce sens, la méthode delete ne renvoie par un nouveau Set à jour mais un boolean indiquant de la réussite de la suppression. Par conséquent l’ancien morceau de code ne peut fonctionner :
Il suffisait simplement de cloner la valeur précédente, de modifier ce nouveau set, et de le renvoyer sous la forme d’un objet.
Au final
La correction d’un bug front, dans un environnement où des tests existent, devrait systématiquement passer en premier par sa caractérisation grâce à des tests.
Il est indispensable d’écrire des tests qui décrivent une fonctionnalité et pas simplement dans le but de faire monter le taux de couverture. Dans le deuxième cas, le résultat pourrait faire perdre plus de temps qu’en gagner.
Je vous propose également quelques ressources supplémentaires afin d’aller plus loin sur les tests :
- Découvrir les tests d’intégration avec React Testing Library : https://medium.com/just-tech-it-now/react-testing-library-ba339ea01f47
- Framework de test end-to-end en Javascript : https://www.cypress.io/
- Série de 5 articles d’Octo traitant de la pyramide des tests : https://blog.octo.com/la-pyramide-des-tests-par-la-pratique-1-5/
