TDD : Test Driven Development
Définition :
Le test-driven development est une technique de développement logiciel pilotée par les tests. Une méthode agile qui pousse les développeurs à corriger les bugs au fur et à mesure de la programmation d’une application. Ça c’est la théorie. En pratique on résume souvent par “on créer les tests et ensuite on écrit le code !”.
Les tests écrits doivent refléter les critères d’acceptances de l’user story et permettent de rapprocher le fonctionnel du code. Écrire ses tests en premier permet de s’assurer que les “use-case” métiers sont biens fonctionnels et couvert par des tests unitaires.
Biais cognitif :
Un gros avantage du TDD est qu’il permet de minimiser les biais cognitifs. Lorsque le développeur réalise ses tests unitaires après avoir fait le développement, il y inclut inconsciemment des biais :
Comme le développeur connaît l’algorithme mis en place, il ne teste que la partie couverte par ses développements et exclut par conséquent tous les cas “non prévus”.
Écrire les tests en amont du codage permet de facto une couverture de test unitaire élevé.
Le TDD pour le développement :
Le processus de développement en TDD se découpe en 5 étapes ou 3 phases:
- Rédiger un test unitaire ne décrivant qu’une seule partie de la problématique posée / règle de gestion / cas fonctionnel
- Confirmer l’échec du test
- Ecrire cette fois-ci un morceau de code suffisant pour qu’il réussisse le test
- Confirmer la réussite du test
- Améliorer le code et contrôler l’absence de régression.
Cela est souvent résumé en trois phases, RED/GREEN/REFACTO.
RED :
Dans cette phase, on se positionne en tant qu’utilisateur et décrivons notre cas d’usage dans un test unitaire. Le test rédigé échoue car rien n’est encore développé, ce test est rouge.
GREEN :
On écrit suffisamment de code pour que la fonctionnalité réponde au besoin.
REFACTO :
L’étape refacto consiste à remanier le code pour mieux le structurer pour qu’il soit plus propre/lisible.
Il faudra par la suite enrichir les tests avec les différentes problématiques et réitérer le processus.
Le TDD pour les bugs de production, premier pas dans le monde du TDD :
Il n’est pas toujours facile de mettre en pratique le TDD dans le cadre de développement de nouvelles fonctionnalités à cause de nombreux allers-retours entre le développement et les tests. En revanche dans le cadre de correction de bug cela peut être plus aisé.
Lorsque l’on travaille sur un incident de production, la première étape consiste à identifier le bug et le reproduire.
Dès lors que l’on possède un scénario de reproduction du bug, on peut coder un test qui reproduit le problème et spécifie la bonne réponse attendue. On est alors dans la phase RED. Tant que l’anomalie ne sera pas corrigée, l’exécution de ce test sera rouge/failed.
On peut ensuite se concentrer sur la résolution du problème et développer la correction. Une fois le correctif appliqué, le test passera au vert = phase RED
Enfin, on peut refactorer le code et vérifier que tous les tests restent au vert = Phase de refacto.
Cela apporte une double satisfaction, le problème est résolu et un test couvre le cas pour s’assurer que cela ne se reproduise plus.
Le développeur termine son travail lorsqu’il à fini son développement et le codage du test unitaire n’est pas une action supplémentaire.
Du TDD en pair programming, et pourquoi pas ?
L’idée est qu’un développeur conçoit les tests unitaires et un second réalise le développement. Les tests peuvent avoir été écrit en amont du développement par son pair. Cela à pour avantage d’avoir un nombre suffisant de tests et des tests qui couvrent tous les cas possibles.
L’inconvénient principal consiste dans le coût de développement plus élevé mais en contrepartie on obtient une meilleure répartition des connaissances au sein de l’équipe de développeurs.
Même si je n’ai pas encore eu l’occasion de mettre en pratique cette approche, nul doute que j’essaierai dès que possible!
Conclusion :
Coder tout un programme en TDD n’est pas quelque chose d’aisé ni de naturel. L’approche par l’analyse d’un bug de production permet de mettre un pas dans la pratique et de faire une première itération des phases du TDD.
L’essayer c’est l’adopter !
Guillaume BRESSON
Développeur enthousiaste depuis plus de 10 ans, j’affectionne particulièrement les sujets backend.
Issu d’une formation d’ingénieur, j’ai commencé ma carrière en intégrant des portails intranet / internet puis je me suis spécialisé sur le développement backend autour de Java/Groovy/Spring.
Mes sujets de prédilection vont de la conception d’api REST à la mise en place de tuyauterie back to back. Je considère que le métier de développeur actuel réside principalement dans l’écriture de tests pertinents.
Mon expérience me permet aujourd’hui de partager les bonnes pratiques autour du développement, des tests (Junit / Mockito /MockMvc) et de l’architecture applicative type DDD (Domain Driven Design).