Plus besoin de présenter cette méthodologie de développement qui se traduit littéralement comme étant le développement piloté par les tests, et qui se décrit souvent par ce fameux cycle RED–GREEN-REFACTOR. 

L’ idée comme cette boucle nous l’indique, c’est d’abord d’écrire un test qui ne va pas passer, d’ ensuite écrire le code minimum pour que le test passe au vert, et enfin, faire en sorte de refactorer le code pour qu’il corresponde exactement à ce qu’on souhaitait.

Les idées reçues de l’approche TDD

Il faut d’abord être un expert technique sur les langages, frameworks, outils, avant de commencer à bien maitriser une nouvelle méthodologie.

C’est faux, tout simplement parce que l’approche TDD permet d’améliorer le design, et de simplifier son code, donc ça permet de devenir un meilleur développeur en ayant de meilleurs réflexes quel que soit le langage.

Le TDD nous ralentit !

Lorsqu’il est bien maitrisé, TDD permet non seulement d’améliorer la qualité de son code, de son design, mais du coup de ne plus perdre son temps constamment sur le débugger et d’être empêtré dans du code legacy.

Impossible de faire du TDD sur un projet existant avec du legacy !

C’est faux, alors évidemment cela demande plus de temps, il faut bien sûr refactorer le code, mais c’est la garantit qu’on aura plus à revenir dessus par la suite.

Il vaut mieux faire ses tests après qu’avant c’est plus efficace !

Là aussi c’est une fausse idée, l’idée du TDD est justement de faciliter le fait de trouver le bon algorithme et de se rendre le travail plus simple. L’approche TDD est bien différente du simple fait de tester.

Quelques avantages

Comprendre les différents avantages du TDD, c’est mettre la rigueur au service du code, et ainsi être capable de naviguer dans le projet sans peur de tout casser, et en ayant confiance dans la maintenabilité du projet.

✔️ L’inutilité d’utiliser le débugger, en effet, puisque qu’avec TDD on réalise ses tests avant, on peut avoir une confiance beaucoup plus grande dans son code !

✔️ Permet d’avoir le code le plus optimisé possible, en effet avec le refactoring constant, on se pose continuellement la question de savoir si ce qui est écrit est justifié, on peut également se référer aux Transformation Priority Premise  dont parle Uncle Bob sur son bog cleancoder.com.

✔️ Permet d’avoir un code dont on est confiant et qu’on n’a pas peur de refactorer, en effet lorsque le code est testé et qu’on sait qu’il est optimisé, si on veut faire une modification plus tard, on pourra aisément faire une transformation ou un ajout sans crainte de détériorer l’ensemble du projet.

✔️ Travailler dans un contexte où on arrête de faire de la correction de bugs pendant 60% de son temps mais où on peut se concentrer sur la création de nouveau code en production.

✔️ Permet de gagner du temps, en effet là-aussi, à partir du moment où cela devient une habitude de travail, on avance plus vite avec l’approche TDD, pas simplement sur du long terme, mais aussi sur des projets plus simples, car la logique algorithmique se met en place plus simplement.

Maintenant qu’on a pu parler des idées reçues et des avantages de l’approche TDD, – et il y’en en a sans doute bien d’autres –, voyons maintenant comment on peut monter en compétence si on n’est pas un expert sur le sujet.

Tout d’abord chaque développeur se doit de faire de la veille constante, doit se remettre en question en permanence, et doit avoir pour habitude de partager ses connaissances.

Plusieurs solutions s’offrent à nous pour monter en compétence sur le TDD :

✔️ Faire parti d’une équipe avec des personnes qui pratiquent TDD au quotidien

✔️ Faire du Pair Programming en TDD pour monter en compétence avec un collègue

✔️ Faire une formation sur du TDD et pratiquer sur des projets personnels

✔️ Participer à des coding dojos en faisant des katas pour s’exercer au TDD

Et vous, comment montez-vous en compétence sur l’approche TDD ?