Test driven development

Cet article est une ébauche concernant l’informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

Consultez la liste des tâches à accomplir en page de discussion.

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.

Sommaire

[masquer]

Cycle de TDD[modifier | modifier le code]

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 :

écrire un premier test ;
vérifier qu'il échoue (car le code qu'il teste n'existe pas), afin de vérifier que le test est valide ;
écrire juste le code suffisant pour passer le test ;
vérifier que le test passe ;
puis réusiner 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 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. 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) 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)

tout est Programmer

Rechercher dans ce blog