Dans un certain sens, j'ai grandi en faisant du TDD (développement piloté par les tests).
Lorsque j’ai commencé, il y a fort fort longtemps, les tests n’existait à peu près pas dans le langage avec lequel je travaillais (Lingo). C’est vraiment lors de mon premier emplois en développement web que j’ai appris à faire le TDD. On m'a enseigné la méthode "rouge-vert-refactor". Nous travaillions souvent en binôme, une personne écrivait d'abord un test, puis l'autre devait écrire le code pour le faire passer, ensuite nous inversions les rôles.
Il y avait néanmoins une vie avant les tests. Je n'ai pas grandi en tombant dans un puits rempli de tests. Le premier programme que j'ai jamais écrit n'était pas un test, c'était un "Hello World". J'ai commencé à programmer à l'adolescence et je n'ai découvert les tests que dix ou douze ans plus tard.
Pourtant, je ne peux plus imaginer programmer sans tests. Plus de quelques centaines de lignes ? Sans tests ? Je commence à sentir l’inconfort. Ce n'est pas seulement une question d'exactitude et de couverture de code cependant . Pas vraiment. Enfin, pas seulement ça. Pour moi, programmer sans tests, je le vois un peu comme cette analogie:
Imagine une compagnie de taxi qui te demande si tu veux un chauffeur avec ou sans permis de conduire pour baisser le coût de la course.
Voila l'impression que me fait un code avec ou sans tests.
Avoir des tests, c'est avoir du code que je peux exécuter rapidement, idéalement en quelques frappes, pour tester d'autres codes que j'ai écrits. C'est une rétroaction immédiate, juste là, dans mon éditeur. Avec des tests, je n'ai pas besoin de lancer ceci, d'attendre, de cliquer là, de lancer cela, de prendre ceci et de le mettre là - je peux simplement faire une simple commande dans Neovim et voir si ça fonctionne. Idéalement, bien sûr.
Ce qu'un REPL et un débogueur sont pour les autres, c'est ce que les tests sont pour moi. Ici, je peux jouer avec une idée en utilisant tous les outils que mon éditeur me donne dans un fichier normal. Je peux zoomer sur un bug en écrivant des tests toujours plus granulaires et en isolant pas à pas la partie défaillante – le tout validé et enregistré. Parfois, j'écris des tests qui échouent pour des fonctionnalités manquantes ou pour des bugs désagréables et je les garde, commentés, pendant des semaines, jusqu'à ce que j'aie le temps de les faire passer. La justesse et la prévention des régressions sont la cerise sur le gâteau. Une suite de tests qui s'exécute en moins d'une seconde vaut la peine d'être utilisée rien que pour la satisfaction qu'elle procure à chaque exécution.
Les tests ont aussi leurs inconvénients, bien sûr. Ils peuvent rendre les changements plus difficiles car vous devez maintenant modifier le système et ses tests. Il peut s'agir de fantômes du passé qui vous murmurent "ça doit être ainsi" à votre oreille lorsque vous n'êtes pas sûr de pouvoir changer quelque chose ou non ; les échos du programmeur qui les a écrits il y a des années et qui est parti. Ils peuvent devenir lents. Ils peuvent être inutiles, un poids mort quand ils ne testent rien. Oui, je reconnais que les tests peuvent avoir leurs inconvénients.
Je ne sais tout simplement pas comment les autres peuvent vivre sans eux.
Merci d'avoir lu.