TDD: Test Driven Development

Définition

Le TDD (Test Driven Developement) est, comme son nom l’indique, une méthode de développement. Elle consiste à écrire les tests avant d’écrire le code. Le but est donc pour l’équipe projet de développer un logiciel construit par la validation de tests plutôt qu’un logiciel construit par le suivi des spécifications. Le TDD est donc une méthode de travail différente du BDD (Behaviour Driven Developement) où le développeur développe en fonction des spécifications fonctionnelles puis écrit les cas de tests unitaires, les autres niveaux de tests étant exécutés ultérieurement.

Fonctionnement du TDD

Le TDD fonctionne par cycle.

·        On écrit d’abord un test.

·        On l’exécute puis on valide que le test est en échec car la fonctionnalité n’a pas été implémentée. Si le cas de test est en succès, alors, s’il est mal été écrit il doit être remanié, sinon la fonctionnalité est déjà implémentée et aucun développement n’est nécessaire.

·        On développe la fonctionnalité jusqu’à ce que le test soit en succès.

·        On « nettoie » le code, pour garder un code propre, de bonne qualité et facilement maintenable.

·        On ré-exécute les tests (celui du cycle et les anciens tests) et s’assure que l’ensemble des tests est encore en succès.

·        On écrit un nouveau test en échec.

Le TDD repose sur l’écriture des tests à mettre en succès. On s’aperçoit également que c’est une méthode incrémentale demandant de nombreuses exécutions. L’automatisation des tests doit donc être envisagée en TDD (comme en SCRUM).

On parle souvent de RGR (Red Green Refactor) lorsque l’on parle du TDD. Red correspond à un cas en échec, Green à un cas en succès et Refactor au nettoyage du code pour améliorer la qualité. Cela est un bon résumé de la méthode TDD.

TDD tests unitaires

Lorsque l’on parle de TDD on parle généralement de TDD pour les tests unitaires. Avec la méthode du BDD les développeurs écrivent leur code puis les tests unitaires. Dans le cas des TDD c’est le contraire, il écrit les tests avant puis doit écrire son code afin de valider ces tests.

Les TDD sur les tests unitaires sont assez faciles à implémenter, en effet, ces tests étant écrit (mais aussi généralement exécutés et maintenus) par les développeurs, seuls ces derniers doivent s’habituer à cette nouvelle méthode.

ATDD (Acceptance TDD)

Le principe ici est d’appliquer la méthode du TDD aux tests d’acceptance (aussi appelés tests métiers). Le cycle reste le même par contre les métiers fonctionnels (MOA, recette…) et techniques (développeurs…) doivent travailler sur ces tests. Cela oblige donc une adaptation au TDD par un plus grand nombre de personnes et encourage également fortement la communication entre ces équipes.

Pourquoi utiliser le TDD ?

Comme pour chaque méthode, le TDD a ses points forts et ses points faibles. Le TDD vise à assurer une bonne qualité du produit de par la certitude que les cas de tests existent et sont exécutés mais aussi par le « nettoyage » récurent du code. Cette méthode incrémentale s’adapte parfaitement aux autres méthodes de travail incrémentales (comme le SCRUM) et aux projets à fort potentiel d’automatisation.

Le TDD est généralement bien perçu par les développeurs, ces derniers voyant par la validation d’un test la valorisation (et un accomplissement) de leur travail alors qu’en BDD, l’écriture du cas de tests arrivant après le développement, elle est souvent perçue comme une corvée.

Le TDD (pour les ATDD) encourage la communication et donc permet d’éviter de mauvaises interprétations.

Enfin, effectuer régulièrement les cas de test permet de détecter plus tôt les bugs, ils sont donc moins cher à corriger.

Sources :

TDD (FR) : http://igm.univ-mlv.fr/~dr/XPOSE2009/TDD/pagesHTML/PresentationTDD.html

TDD (GB et plus complet): http://agiledata.org/essays/tdd.html

ATDD : http://blog.neoxia.com/l%E2%80%99a-t-d-d-une-approche-efficace-de-developpement-logiciel/