Test-Driven Development (TDD), ou développement piloté par les tests en français, est une méthode de développement de logiciel qui consiste à concevoir un logiciel par des itérations successives très courtes (ou petits pas), telles que chaque itération est accomplie en formulant un sous-problème à résoudre sous forme d'un test avant d'écrire le code source correspondant, et où le code est continuellement remanié dans une volonté de simplification.
Les tests tels qu'ils sont mis à profit dans TDD permettent d'explorer et de préciser le besoin, puis de spécifier le comportement souhaité du logiciel en fonction de son utilisation, avant chaque étape de codage.
Le logiciel ainsi produit est tout à la fois pensé pour répondre avec justesse au besoin et conçu pour le faire avec une complexité minimale. On obtient donc un logiciel mieux conçu, mieux testé et plus fiable, autrement dit de meilleure qualité.
Quand les tests sont écrits après codage, comme c'est le cas traditionnellement, les choix d'implémentation contraignent l'écriture des tests : les tests sont écrits en fonction du code, et si certaines parties du code ne sont pas testables, elles ne seront pas testées.
Au contraire, en testant avant de coder, on utilise le code avant son implémentation, de sorte que les contraintes définies par les tests s’imposent à l'implémentation : le code est écrit en fonction des tests. Le fait d'écrire les tests avant le code en TDD conduit donc à des implémentations testables, c'est-à-dire faciles à tester et entièrement testables. Or la testabilité du code favorise une meilleure conception par un couplage lâche et une cohésion forte, ce qui évite des erreurs de conception courantes.
Comme chaque test correspond à un changement minimal de code, un test unique permet de faire un lien évident entre une régression et sa cause s'il échoue.
Ce lien fait de l'exécution des tests un moment charnière dans un cycle de TDD : on capture l'état instantané du logiciel et on détecte d'éventuelles régressions à la suite du dernier changement.
En effet, on veut à tout prix éviter de modifier le code en présence d'une régression. Dans le cas contraire, on ne saurait dire avec certitude si les tests échouent à cause du dernier changement ou d'un changement antérieur. C'est en cela que les tests déjà écrits constituent un filet de sécurité contre des accidents de parcours où l'on perdrait le lien entre changement et régression. Ce filet de sécurité permet d'envisager avec sérénité n'importe quelle modification du code, qu'il s'agisse d'une transformation (modification qui affecte le comportement) ou d'un remaniement (modification qui n'altère pas le comportement), ainsi que les livraisons du logiciel de version en version.
Comme les tests sont écrits avant le code, ils jouent plusieurs rôles dans TDD : ils servent d'abord à résoudre un problème en guidant le codage à chaque étape, ils fournissent ensuite un filet de sécurité contre les régressions et, enfin, ils documentent le comportement du logiciel. Grâce à son utilisation des tests, TDD fait gagner en productivité de plusieurs façons.
Le cycle rouge-vert-refactor vous guidera dans l'écriture de vos tests.
Rouge : Vous écrivez un test simple qui échouera avant même d'avoir du code qui l'accompagne. Le test échoue, évidemment, sans le code. Du coup, le test est rouge.
Vert : Vous écrivez le code le plus simple possible pour faire passer le test, même si le code est un peu ridicule ou simplifié. Le test réussit, il est donc vert.