Faire nos tests unitaires avant ou après le code n’a pas un gros impact sur l’issue des petits projets. Les choses sont différentes pour les grands projets. Dans un article de 2016, Robert C. Martin revient sur cette réflexion dans un dialogue amusant mais éclairant :

Le TDD ne fonctionne pas.

Vraiment ? C’est étrange. J’ai toujours constaté que ça fonctionnait plutôt bien.

Selon une nouvelle étude, si.

Encore une étude ?

Oui, une étude approfondie qui a répété une autre étude réalisée il y a quelques années. Les deux ont montré que le TDD ne fonctionne pas. La nouvelle utilise une approche d’analyse aveugle multicentrique. Ça semble concluant.

Les auteurs considèrent-ils cela comme concluant ?

Les auteurs recommandent de poursuivre les études. Mais ils sont probablement juste modestes. Les données sont plutôt convaincantes.

Quelles sont les données ?

L’étude montre que les affirmations sur le TDD sont fausses. Le TDD ne vous fait pas aller plus vite ; il ne réduit pas les défauts ; et il ne vous aide pas à écrire un meilleur code.

C’est très étrange. Je pense que le TDD me fait aller plus vite, améliore mon code et ma précision. Je connais d’autres personnes qui ont dit la même chose. Donc je suis perplexe sur la raison pour laquelle cette étude montrerait quelque chose de différent.

Eh bien, c’est ce qu’elle a fait. DHH avait raison. Le TDD est mort.

Hmmm. D’accord, donc qu’est-ce exactement que les auteurs ont étudié ? Comment sont-ils parvenus à cette conclusion ?

Je ne sais pas, je sais seulement qu’il y a eu une étude.

Comment as-tu entendu parler de cette étude ?

J’ai lu un blog à ce sujet. À la fin, l’auteur a déclaré que l’étude l’avait amené à reconsidérer le TDD. Il pensait que ça fonctionnait auparavant.

D’accord, eh bien, regardons l’étude. Hmmm. Oui, ici il est dit qu’ils ont comparé le TDD au TLD.

Qu’est-ce que le TLD ?

Le développement des tests APRÈS. C’est lorsque vous écrivez vos tests unitaires après avoir écrit votre code.

Voyez ? Donc l’étude a montré qu’il est préférable d’écrire vos tests en dernier !

Hmmm. Non, cela ne semble pas être ce que l’étude a montré. En fait, l’étude a conclu qu’il n’y avait pas de différence significative.

D’accord, très bien. Donc si j’écris mon code, puis j’écris mes tests, c’est aussi bon que le TDD.

Eh bien, pas tout à fait. Du moins, ce n’est pas ce que l’étude a montré. L’étude a demandé aux personnes pratiquant le TLD de travailler par « petits morceaux ».

Petits morceaux ?

Oui. Les personnes pratiquant le TLD écrivaient un peu de code de production, suivi d’un peu de code de test.

Oh. Je vois. Donc ils écrivaient du code de production pendant 10 minutes, puis ils écrivaient des tests unitaires pendant dix minutes, ou quelque chose comme ça.

Eh bien, peut-être. Mais regardez ici, il est dit que tous les participants étaient formés au TDD. Et ensuite, certains d’entre eux ont été invités à faire du TLD en petits morceaux.

D’accord. Donc ma déclaration tient toujours. Ils ont écrit du code de production, puis ils ont écrit des tests, et cela n’a pas d’importance.

Permettez-moi de vous demander comment vous écririez des tests unitaires après le code de production, mais par petits morceaux.

J’écrirais un peu de code de production – suffisamment pour réussir un ou deux tests – puis j’écrirais ces tests.

Comment sauriez-vous combien de code réussirait un ou deux tests ?

Je penserais à quelques tests à réussir, puis j’écrirais le code qui réussirait ces tests. Ensuite, j’écrirais les tests.

Et puisque vous avez été formé au TDD, ce genre de processus de réflexion vous serait naturel, n’est-ce pas ?

Hum. Hmmm. Je crois comprendre votre point. Les adeptes du TLD faisaient du TDD dans leur tête, puis inversaient simplement l’ordre.

Exact. Pour travailler par petits morceaux, ils devaient imaginer les tests qu’ils allaient écrire, afin de pouvoir écrire du code de production qui était testable.

Donc peut-être que cette étude n’étudiait pas ce qu’ils pensaient étudier.

Il me semble qu’ils essayaient d’étudier l’ordre d’écriture des tests, plus que le processus du TDD. Dans leur effort pour réduire le nombre de variables, ils les ont involontairement éliminées toutes. Ils ont obligé les participants pratiquant le TLD à utiliser le processus du TDD avec de courts cycles, ce qui les a amenés à diriger le code de production en pensant d’abord aux tests.

D’accord. Peut-être. Mais quand même, ces adeptes du TLD ont écrit leurs tests en dernier. Donc au moins l’étude a montré que vous n’avez pas vraiment besoin d’écrire les tests d’abord, tant que vous travaillez avec des cycles très courts.

Bien sûr. La partie vraiment efficace du TDD est la durée du cycle, pas tellement l’ordre d’écriture des tests. La raison pour laquelle nous écrivons les tests d’abord est que cela nous encourage à garder les cycles très courts.

Donc ce que l’étude a montré, c’est que les personnes qui travaillent avec de courts cycles n’ont pas besoin de se soucier d’écrire les tests d’abord, tant qu’elles continuent de travailler avec de courts cycles.

C’est probablement une affirmation juste. Cependant, regardez ici. Le problème que les participants devaient résoudre était « The Bowling Game ». Il s’agit d’un problème très simple. En fait, ils ont dit que toute la session de programmation a duré trois heures.

Est-ce important ?

Bien sûr. L’avantage d’écrire les tests d’abord est _la discipline. Écrire le test d’abord permet de garder des cycles courts et une couverture élevée sur de longues périodes.

D’accord, mais si vous avez assez de discipline interne pour maintenir vos cycles courts, alors l’étude montre qu’il n’importe pas si vous écrivez vos tests d’abord.

C’est un gros « si », mais oui. L’étude montre que si vous prenez un groupe de personnes formées au TDD, puis leur demandez de tout garder pareil, y compris la durée de leurs cycles, et de simplement changer l’ordre des tests, alors en trois heures de programmation, vous ne verrez pas beaucoup de différence.

Oui. Oui. C’est ce que montre l’étude.

Donc, en réalité, l’étude faisait une distinction sans différence.

Eh bien.. Heu, ils n’ont trouvé aucune différence, donc je suppose que c’est vrai.

Donc l’étude n’a pas montré que le TDD ne fonctionne pas, n’est-ce pas ?

Non, je suppose que non.

Qu’est-ce qu’elle a montré alors ?

Je pense qu’elle a montré que vous ne pouvez pas interpréter les conclusions d’une étude sans lire l’étude.