Qu’est-ce que le TDD ?
TDD est l’acronyme de Test-Driven Development, que l’on peut traduire par “développement dirigé par les tests”. L’idée est simple : lorsque l'on souhaite développer une nouvelle fonctionnalité, on commence par écrire le test qui vérifie son fonctionnement. Dans un deuxième temps, la fonctionnalité est développée pour que le test soit validé. Et rien de plus !
Se concentrer sur la fonctionnalité évite d'écrire du code sans qu’il réponde à une exigence satisfaite par un test validé.
Oui, cela arrive, et même souvent ! 😣
Le principe consiste ensuite à travailler en petits cycles itératifs où l’on va :
écrire le minimum de code possible pour faire passer le test ;
enrichir la base de tests avec un nouveau test ;
écrire à nouveau le minimum de code pour faire passer le test ;
et ainsi de suite…
Cette pratique nous vient de Kent Beck, l’un des signataires du Manifeste Agile. Il encourage une conception simple de nos applications et rend le développeur plus confiant dans la capacité de son code à faire correctement ce qu'il souhaite, sans qu'il s'y cache quelques bugs.
Les étapes du cycle du TDD
Regardons plus en détail les différentes étapes du cycle TDD.
1. Écrire un test
La première chose à faire, lorsque l’on a besoin d’une nouvelle fonctionnalité, est d’écrire un test. Cela implique de comprendre la fonctionnalité que l’on doit développer, ce qui est une très bonne chose.
Oui, il m'est déjà arrivé de commencer à développer sans forcément comprendre tout ce que je devais faire... ça donne confiance, hein ? 😜
2. Exécuter le(s) test(s)
Il faut ensuite exécuter le test que l'on vient d'écrire.
Le test doit échouer, vu qu’aucun code n’a été écrit pour le faire passer. En général, il ne compile pas non plus, car la méthode/classe n’existe même pas.
3. Écrire le code
Ensuite, on écrit le minimum de code permettant de faire passer le test, et seulement le minimum. Si le code écrit n’est pas beau, ou fait passer le test de manière inélégante, ce n’est pas grave. On relance tous les tests pour s’assurer que tout fonctionne.
4. Remaniement du code
Dans cette phase, nous avons l’opportunité d’améliorer le code que nous avons écrit. Cela permet de voir s’il ne peut pas être simplifié, mieux écrit, rendu générique. On retire les duplications, on renomme des variables, des méthodes, des classes, etc., afin que le code soit bien propre et exprime clairement son intention. On peut séparer les responsabilités, extraire potentiellement des patrons de conception, etc.
En bref : on améliore le code !
5. On recommence à l'étape 1 !
Le cycle recommence. Si la fonctionnalité que l’on a écrite peut être mieux couverte par d'autres tests, si l’on doit introduire d'autres cas pour tester la fonctionnalité, alors on écrit un nouveau test. Puis on écrit du code pour le faire passer, on améliore le code, on écrit un nouveau test, etc.
Les bénéfices du TDD
Nous avons donc un cycle vertueux, qui améliore notre base de tests, nous rend plus confiants dans notre code et le rend plus propre, plus robuste et plus facile à maintenir.
On appelle en général ce cycle red/green/refactor.
Comme on l’a vu, le TDD rend de facto le code prêt à être testé. Cela améliore son design de testabilité. Grâce au TDD, le design d’une classe ou d’un code émerge de lui-même. En effet, en se concentrant sur le cas d’usage qui découle du test écrit, le travail se fait d’abord sur le contrat et ensuite sur l’implémentation.
Beaucoup d’études ont été faites sur le TDD. Il en ressort que les développeurs qui suivent ces pratiques ont un code de meilleure qualité et sont plus productifs.
L’approche est plus itérative et l'on avance petit à petit. Des résultats sont rapidement visibles et cela évite de se perdre dans plusieurs jours de développement avant de pouvoir espérer obtenir quelque chose qui fonctionne, voire qui compile.
Et bien sûr, vous aurez plein de tests pour votre filet de sécurité et la confiance en votre code.
