Le test-driven development (TDD) est une technique de développement logiciel qui prend à rebours la méthode “traditionnelle”. Elle propose de commencer par écrire les tests unitaires avant de s’attaquer au code source d’un projet.
Le cycle préconisé par TDD comporte cinq étapes :
- 1. écrire un premier test
- 2. vérifier qu'il échoue (ce qui est logique, car le code qu'il teste n'existe pas) ; cet échec confirme que le test est valide
- 3. écrire le code minimum suffisant pour passer le test
- 4. vérifier que le test passe
- 5. puis refactoriser le code, pour améliorer ses performances et sa qualité tout en gardant les mêmes fonctionnalités
Les promoteurs de cette méthode soulignent les avantages suivants :
- Certitude que les tests seront écrits (par rapport à la méthodologie classique où les tests sont souvent remis à plus tard par les développeurs, par manque de temps, pression des clients pour le développement de nouvelles fonctionnalité ou manque d’intérêt)
- Nécessité pour le développeur de réfléchir en avance de phase aux détails de sa future implémentation, afin de coder le test ; cette réflexion initiale permet de clarifier la conception, et d’éviter d’écrire du code inutile
- Filet de sécurité pour éviter les régressions : toutes les fonctionnalités spécifiées du système sont de facto couvertes par des tests
- Méthodologie poussant à découper les fonctionnalités en petit incréments testables, ce qui est conforme aux préceptes de la méthodologie agile
Ce mode de développement gagne en popularité dans le monde de l’IT, avec des bénéfices reconnus par la grande majorité des développeurs.
Quelques critiques, minoritaires, pointent que cette méthodologie ne s’adapte pas à tous les cas et notamment aux fonctionnalités de petite taille : ceux-ci expliquent que les développeurs TDD ont parfois tendance à écrire du code inutile (puisque les demandes du client évolue ou que le développeur lui-même change d’architecture technique en cours de route).
