J’entends et lis parfois que ça prend du temps d’écrire des tests unitaires et de pratiquer le Test-Driven Development. Que c’est bien plus long que de ne pas en faire. Je ne suis pas en phase.

J’ai la conviction que ça ne prend pas forcément plus de temps de travailler en TDD. On est sensiblement sur la même longueur, parfois même plus rapide parce que ça nous guide. On est très loin du laïus “c’est une perte de temps”, surtout lorsque l’on regarde sur différents horizons de temps.

Il n’y a d’ailleurs pas que le temps qui entre en jeu, d’autres bénéfices gravitent autour de l’écriture des tests et de la pratique du TDD. Pour étayer mes affirmations, j’ai envie d’en parler à travers plusieurs prismes.

J’ai une mauvaise utilisation du TDD

Pour le premier prisme, je prends un développeur qui pratique le TDD mais qui l’utilise mal, qui ne le maîtrise pas. Je commence par ce postulat parce que c’est sûrement là qu’il y a le plus de confusion et de mécompréhension. Les personnes qui ne maîtrisent pas l’art de tester et du TDD se forgent un avis sur la base d’une expérience incomplète.

Qu’est-ce que c’est, ne pas maîtriser ? Penser que ça se résume à écrire un test en premier, que c’est purement de la technique (versus métier), ou que ça se limite à suivre le Red-Green-Refactor, par exemple.

En adoptant une mauvaise pratique, on va se mettre des bâtons dans les roues. On va vouloir tout mocker, on va tester l’implémentation, on ne va pas faire de petites étapes, etc. Résultat, on va trouver ça plus long. On va peut-être préférer ne pas faire de TDD, finalement. C’est plus long et il y a un tas de trucs chiants à faire, pourquoi s’emmerder.

Dans ce contexte, la méthode est mal comprise et mal appliquée. C’est probablement plus long de pratiquer le TDD, oui. Mais peut-on juger la méthode dans ces conditions ? J’y répondrais par une autre question. Est-ce qu’une voiture est lente parce qu’on roule avec le frein à main ? Ou parce qu’on ne sait pas comment passer les vitesses ? Non.

=> Oui, une mauvaise application du TDD peut demander davantage de temps. Non, dans ce contexte, c’est inexact de déduire qu’une bonne pratique du TDD prend du temps.

J’apprends le TDD

Dans ce second prisme, j’introduis une nuance : un développeur qui s’exerce à pratiquer le TDD mais qui ne le maîtrise pas encore parce qu’il est en phase d’apprentissage. La différence avec le premier prisme ? Il a conscience de la bonne pratique du TDD et il s’améliore pour y arriver. Il ne va pas mal faire tout en supposant qu’il maîtrise la méthode.

Disons les choses. Le TDD, c’est difficile. Ça demande du temps pour le maîtriser. Ça demande de s’entraîner, de répéter, de s’améliorer. Mais pour autant, c’est la phase d’apprentissage qui requiert du temps. Ce n’est pas l’application de la méthode elle-même. Encore une fois, juge-t-on la vitesse d’une voiture avec un pilote qui apprend à passer les vitesses ? Non.

Ok. Et durant cet apprentissage alors, à quel point ça prends du temps de faire du TDD ? Ça dépend. Ça dépend du contexte, ça dépend du niveau de compétence que l’on a acquis à cet instant.

Il y a des situations où l’on ne sera pas encore à l’aise, on devra ralentir pour bien faire, on prendra davantage de temps sur le moment. À l’inverse, il y a des situations où l’on sera guidé par le TDD et où l’on obtiendra plus rapidement un bon résultat. On va commencer à bénéficier des effets positifs (j’en parlerais après).

=> Oui, l’apprentissage du TDD demande du temps. Non, on ne peut pas dire que la pratique elle-même, une fois maîtrisée, prend du temps.

J’écris mes tests après

Je me mets maintenant dans le prisme d’un développeur qui écrit ses tests après coup. Que se passe-t-il si je me mets à faire du TDD ? On pourrait se dire que l’on va prendre davantage de temps, on écrit déjà des tests, pourquoi se compliquer la vie à s’ajouter une méthode ?

Eh bien, dans ce contexte, pratiquer le TDD sera probablement plus efficace et plus rapide. Le TDD va guider l’écriture de l’implémentation. On obtiendra une meilleure conception, on avancera par petites étapes et on sera guidé par le comportement métier. Ce sera une aide pour écrire de meilleurs tests et un meilleur code.

De fait, on s’évitera les pièges d’écrire du code non-testable, d’en faire trop, ou de ne pas correctement retranscrire le métier, comme on pourrait le faire en écrivant les tests a posteriori.

En écrivant les tests après, on subit l’implémentation. Et plus on attend pour tester, plus on subit. Il y aura davantage de changements à effectuer, le coût va augmenter. Le refactoring sera d’ailleurs difficile ; les tests ne sont pas écrits, on n’a pas encore notre filet de sécurité en place.

=> Non, ce n’est pas plus long de pratiquer le TDD lorsque l’on écrit déjà des tests a posteriori. C’est un gain de temps, et en plus, un gain de qualité.

Je ne teste pas

Je termine avec un dernier prisme qui n’en ait pas moins intéressant : celui du développeur qui ne teste pas. Alors là, réflexe, on va se dire que c’est bien plus long. Non seulement, il faut écrire du code supplémentaire (les tests), et en plus, il faut se coltiner une discipline stricte. On va perdre du temps, non ? Je propose de regarder sous deux horizons de temps.

Court terme

À court terme, sur l’instant, le TDD va nous guider. C’est une de ses principales forces. Il nous guide pour concevoir le code de production, l’implémentation. Il nous guide pour retranscrire le métier. Il nous offre une boucle de feedback extrêmement rapide pour créer et améliorer.

On prends le temps de bien faire et de réfléchir, mais pour autant, ce n’est pas forcément plus long. Parce qu’on se concentre sur l’essentiel en progressant par petites étapes, parce qu’on est guidé pour coder l’implémentation, parce qu’on a un feedback rapide contrairement aux tests manuels.

La pratique du TDD ne va pas seulement nous faire écrire des tests avant de coder, elle va nous aider à coder, à concevoir. Au final, on ralentit tout en gagnant du temps, pour mieux faire. On passe sensiblement le même temps à développer notre fonctionnalité.

Dans certains contextes, on est plus rapide, parce qu’on se serait perdu en chemin sans le TDD, parce qu’on aurait fait trop compliqué ou parce qu’il y a beaucoup de logique. On perd vite du temps à explorer sans test et sans guide. Dans quelques autres contextes, ça peut être plus long de pratiquer le TDD, mais c’est sans compter les effets obtenus à plus long terme.

Moyen et Long terme

À moyen et long terme, on va obtenir de nouveaux bénéfices grâce à la pratique du TDD. Les tests vont couvrir notre code et vont faciliter le refactoring et réduire les régressions. On va gagner du temps.

La facilité de faire du refactoring va aider à améliorer continuellement le système. On va le maintenir et le faire évoluer plus facilement. On va le changer facilement. On va gagner du temps.

On aura du code et des tests qui reflètent mieux le métier et les cas d’utilisations. On va mieux comprendre notre système. On va mieux échanger avec les autres. On va gagner du temps.

Bref

Au final, en regardant à travers ces différents prismes, on peut observer que les situations où un développeur trouve que c’est plus long de pratiquer le TDD est peut-être à décorréler de la méthode elle-même. Souvent parce qu’elle n’est pas encore maîtrisée.

Dès lors qu’on a une bonne pratique du TDD, des bénéfices apparaissent immédiatement, à court terme. La force que le TDD propose pour guider et donner du feedback rapide est assez puissante pour être d’une grande aide pour le développeur tout en ne faisant pas perdre de temps.

Ces effets s’accentuent à plus long terme, et d’autres viennent s’ajouter. On y voit un cercle vertueux d’amélioration continue. Ce n’est plus juste une question de temps, on y gagne sur plusieurs niveaux.