TDD, Test Driven Development

TDD

Le TDD ou développement piloté par les tests (Test Driven Development) constitue la première pierre technique à mettre en œuvre pour respecter l’un des principes fondamentaux de l’agilité : Accueillir positivement les changements de besoins, même tard dans le projet. Appliquer cette pratique dès le début et bien comprendre son fonctionnement vous permettrons de partir sur de bonnes bases.

Qu’est ce que le TDD ?

Le TDD est un principe de développement qui préconise d’écrire les tests unitaires avant d’écrire le code source d’un logiciel. Cette méthode, qui semble être à contre courant d’un cycle de développement traditionnel, apporte bon nombre d’avantages. Elle force le développeur à réfléchir sur comment il va devoir structurer son code pour que celui-ci soit testable. Elle permet au développeur de concevoir une API claire, car pour écrire son test, il a besoin d’imaginer par avance comment son API va-t-être utilisée. Elle met le développeur en confiance, car il sait que tout ce qu’il développe est systématiquement testé par un automate.

Comment ça marche ?

Le cycle du TDD se fait en 3 grandes étapes appelées Red, Green, Refactor (pour Rouge, Vert, Remaniement).

Le développeur écrit un test unitaire, et vérifie que celui-ci échoue (car le code qu’il teste n’existe pas). Avec cette étape, le test unitaire est référencé par le système comme étant rouge. Ensuite, le développeur écrit le code suffisant pour que le test passe au vert. Pour finir, le développeur remanie son code en s’assurant que l’ensemble des tests unitaires écrits précédemment restent verts.

Une anecdote pour illustrer les bienfaits du TDD

Au cours d’un gros projet, le client demande à ce que des fichiers qui sont déposées dans un répertoire au fil de l’eau puissent être intégrés automatiquement dans une GED (Gestion Electronique de Document) Visiblement, rien de sorcier la dedans : un simple FileSystemWatcher qui se mettra en écoute sur le répertoire enverra les fichiers via un Repository pour l’enregistrer en GED. Le développeur s’interroge : est-il vraiment nécessaire de faire du TDD pour un programme qui nécessite à peine une trentaine de lignes de code ? Ne va-t-on pas perdre plus de temps qu’autre chose pour une fonctionnalité si triviale ? Comme il travaille sur un projet Agile, son équipe est intransigeante sur le sujet : tous les programmes doivent être faits en suivant les principes du TDD, même s’il n’y a que quelques lignes de code ! En développant par pas successif de Red, Green, Refactor, il prend conscience que si les fichiers sont assez volumineux, et le réseau suffisamment lent, une situation particulièrement dangereuse peut créer des conditions de concurrences totalement aléatoire ! Et comme il travaille en TDD, il encadre parfaitement ce cas de figure à l’aide de tests appropriés.

Les tests unitaires ont donc permis au développeur d’anticiper un cas complexe qui aurait été extrêmement difficile à comprendre et à reproduire en production s’il avait décidé de l’implémenter sans faire de TDD.

Quelques mois plus tard, le client est tellement satisfait par ce petit programme qu’il demande à ce que celui-ci puisse envoyer les fichiers sur du FTP, du WEBDAV ou un partage réseau. Le programme n’ayant pas été conçu pour une telle flexibilité, il doit être partiellement revu. Grace à tous les tests unitaires, le développeur en charge de cette évolution peut travailler sereinement, et apporte une mise à jour au client en seulement quelques heures. Si cette application n’avait pas été développée via une approche pilotée par les tests, de nombreux bugs aléatoires se seraient déclarées en production, ces bugs auraient pris énormément de temps à être diagnostiqués par les services techniques, le développeur n’aurait jamais pu les reproduire, et le client aurait perdu confiance en son prestataire au vue de son impuissance à résoudre ce problème. Pire encore, si le client avait vraiment besoin d’une évolution du produit, le remaniement de l’application aurait certainement généré des effets de bord très nocifs. Cela aurait soit obligé les développeurs à réécrire complètement l’application, soit à convaincre le client que l’évolution demandée n’est pas possible.

Les tests unitaires permettent de faire émerger une bonne conception, révèles les cas problématiques avant qu’ils ne se déclarent en production, et sont les garants de la non régression lors de l’évolution du produit. De ce fait, si le TDD est considéré comme une option dans beaucoup de projets, elle n’est pas négociable dans le cadre d’un développement Agile !