Écrire les tests avant le code : le TDD expliqué simplement
Non, ce n'est pas une erreur d'écrire les tests avant le code. C'est le principe même du développement piloté par les tests, et il change la donne.
1 min de lecture
« Es-tu certain de ne pas te tromper ? » Une personne du milieu des affaires m’a un jour lancé cela, un brin condescendante, quand j’ai expliqué qu’en TDD on écrit les tests avant le code. Pourtant, c’est exactement le principe.
Savoir avant de coder
Quand on programme une fonction, on doit savoir quels paramètres elle recevra et quel résultat elle doit retourner. Si ce n’est pas clair, c’est qu’on n’est pas encore prêt à coder.
Le TDD — Test Driven Development, ou développement piloté par les tests — consiste à écrire d’abord nos cas limites, comme si on utilisait déjà la fonction, puis à écrire le code pour que ces tests réussissent. On relance ensuite les tests autant de fois que nécessaire jusqu’à ce que tout passe au vert.
Un garde-fou pour évoluer
Cette méthode permet aussi de refactoriser en confiance : on optimise le code en étant certain que la fonctionnalité reste intacte, puisque les tests servent de garde-fou. Ils deviennent une forme de documentation vivante, qu’on peut rejouer à volonté lors des évolutions.
Résultat : des tests durables, un développement plus rapide, un code de meilleure qualité et moins d’anomalies. La personne en face semblait sceptique. C’est pourtant une pratique que j’ai utilisée et qui apporte un vrai plus.