Test driven development

Un article de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche

Le 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 à écrire chaque test, notamment des tests unitaires, avant d'écrire le code source d'un logiciel, de façon itérative.

Cycle de TDD[modifier | modifier le code]

Cycle global TDD
Une représentation graphique du cycle de la méthode Développements Pilotés par les Tests (TDD)

Le cycle préconisé par TDD comporte cinq étapes :

  1. écrire un seul test qui décrit une partie du problème à résoudre ;
  2. vérifier que le test échoue, autrement dit qu'il est valide, c'est-à-dire que le code se rapportant à ce test n'existe pas ;
  3. écrire juste assez de code pour que le test réussisse ;
  4. vérifier que le test passe, ainsi que les autres tests existants ;
  5. puis remanier le code, c'est-à-dire l'améliorer sans en altérer le comportement.

Ce processus est répété jusqu'à résoudre le problème d'origine dans son intégralité.

Intérêt[modifier | modifier le code]

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é.

En écrivant les tests d'abord, on utilise le programme avant même qu'il existe. On s'assure ainsi que le code produit est testable unitairement. Il est donc impératif d'avoir une vision précise de la manière dont on va utiliser le programme avant même d'envisager son implémentation. Cela évite souvent des erreurs de conception dues à une précipitation dans l'implémentation avant d'avoir défini les objectifs.

De plus, le fait d'avoir des tests augmente la confiance en soi du programmeur lors du réusinage du code : il sait qu'à un moment donné les tests ont réussi. Il peut ainsi se permettre des changements radicaux de design en étant sûr, à la fin, d'avoir un programme se comportant toujours de la même façon (si les tests réussissent toujours). L'utilisation de TDD permet la construction conjointe du programme et d'une suite de tests de non-régression. TDD est souvent associé, particulièrement dans la méthode XP, à la programmation en binôme. Pour expliquer les rôles des deux acteurs impliqués, il est généralement utilisé la métaphore du rallye automobile. Pour chaque fonctionnalité à réaliser, l'un des développeurs, nommé copilote, code le test. Ensuite, le pilote code la fonctionnalité elle-même. À chaque nouvelle fonctionnalité ajoutée, l'ensemble test-code ainsi réalisé sera de nouveau exécuté, réduisant ainsi au maximum le risque de régression.

Afin de pouvoir mettre en œuvre cette technique, il sera imposé aux utilisateurs, dès la spécification des fonctionnalités, de formaliser la façon dont ils la testeront lors de la recette. Dans le cas d'un développement incrémental, le responsable de la dynamique applicative s'interdira d'accepter dans l'incrément à réaliser une fonctionnalité dont les cas de tests n'auront pas été préalablement formalisés. Pour améliorer encore un peu plus la qualité du code, cette technique pourra être couplée à une autre (Test Fail First) qui consiste à demander en premier lieu au pilote de coder avec une erreur afin de vérifier le comportement de l'applicatif ainsi que le fait que cette erreur sera éventuellement « trappée ». Cette étape réalisée, le pilote codera de nouveau la fonctionnalité sans erreur et si possible plus efficacement (refactoring). L'ensemble des tests sera alors repassé de nouveau.

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • (en) Kent Beck, Test Driven Development: By Example, Addison-Wesley, , 240 p. (ISBN 0-321-14653-0)
  • (en) Lasse Koskela, Test Driven: TDD and Acceptance TDD for Java Developers, Manning, , 470 p. (ISBN 1-932-39485-0)

Liens externes[modifier | modifier le code]