Test Driven Development

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Le Test Driven Development (TDD) ou en français développement piloté par les tests est une technique de développement de logiciel qui préconise d'écrire les tests unitaires avant d'écrire le code source d'un logiciel.

Le cycle de TDD[modifier | modifier le code]

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

  1. écrire un premier test ;
  2. vérifier qu'il échoue (car le code qu'il teste n'existe pas), afin de vérifier que le test est valide ;
  3. écrire juste le code suffisant pour passer le test ;
  4. vérifier que le test passe ;
  5. puis refactoriser le code, c'est-à-dire l'améliorer tout en gardant les mêmes fonctionnalités.

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

Ces tests permettent aussi de préciser les spécifications du code, et donc son comportement ultérieur en fonction des situations auxquelles il sera exposé. Ce qui facilite la production d'un code valide en toutes circonstances. On obtient donc un code plus juste et plus fiable.

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 de la refactorisation 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.

Le 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 (en)) 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,‎ 2002, 240 p. (ISBN 0-321-14653-0)
  • (en) Lasse Koskela, Test Driven: TDD and Acceptance TDD for Java Developers, Manning,‎ 2007, 470 p. (ISBN 1-932-39485-0)

Liens externes[modifier | modifier le code]