Dans son article de janvier 2012, Robert C. Martin est extrêmement radical sur le TDD (Test Driven Development). Contrairement à la position que nous avions commencé à adopter jusqu’à présent en relativisant l’intérêt des TDDs pour les petits projets ou dans certaines situations, il affirme qu’il n’existe aucune situation où les TDDs ne sont pas avantageux, avec un certain sens de l’humour et de la conviction :

« Il y a un bit que nous devons flipper dans nos esprits. C’est juste un bit, « LE BIT ». Certains d’entre nous l’ont déjà inversé. Le reste d’entre nous doit inverser LE BIT dès que possible.

Une fois que nous aurons inversé LE BIT, nos vies seront plus faciles, notre code sera plus propre, nous terminerons nos projets logiciels plus rapidement, notre logiciel fonctionnera mieux, et de joyeux lapins sauteront gaiement sur les collines sous des arcs-en-ciel doubles tout du long !

Avant de vous dire ce qu’est LE BIT, laissez-nous vous montrer un exemple d’un article produit sans avoir inversé LE BIT. L’article est ici, et il a été écrit par quelqu’un nommé Tom Fischer. Au moment où nous écrivons ce blog, l’article de Fischer a été lu 80 000 fois. Ce sont 80 000 personnes qui ont été influencées par la mauvaise polarité du BIT.

L’article de Fischer soutient que les tests unitaires ne sont pas toujours nécessaires. Il utilise des graphiques et des diagrammes colorés ingénieux pour étayer ses arguments. Ces arguments sont doubles.

1. Les tests unitaires prennent du temps et peuvent retarder les projets, ce qui peut entraîner des pertes financières en raison des opportunités manquées.
2. Les tests unitaires ne détectent pas tous les bogues, car de nombreux bogues sont des bogues d’intégration, pas des bogues dans les composants testés unitairement.

Fischer continue en disant que les tests unitaires sont formidables et peuvent résoudre de nombreux problèmes, etc., etc., blah, blah. Mais ensuite, il efface toutes ces paroles positives et amicales en concluant par ceci :

Nous ne pouvons plus nous fier à une acceptation générale du mythe selon lequel les tests unitaires sont une panacée universelle, mais nous devons nous concentrer sur les aspects du développement où ils sont les plus efficaces et être prêts à en justifier activement l’utilisation.

Oh mon Dieu ! Nous devons être prêts à justifier activement l’utilisation des tests unitaires ? Soyez avertis ! Les Escadrons de Conformité aux Tests Unitaires feront bientôt le tour. Toute personne qui ne peut pas justifier activement ses tests unitaires sera dûment punie !

Qui écrira des tests unitaires si nous devons justifier activement leur utilisation ? Qui serait assez fou pour prendre ce risque ? Donc, nous pouvons résumer l’article de M. Fischer avec la phrase suivante : « N’osez pas écrire de tests unitaires à moins que vous NE SACHIEZ, et que vous puissiez justifier activement, que vous avez suffisamment de temps. »

Donc, la question est la suivante : Qui a suffisamment de temps ? Qui, parmi nous, a des horaires assez flexibles pour pouvoir justifier activement le risque d’écrire des tests unitaires ? Qui, parmi nous, travaille dans un environnement où les coûts d’opportunité et le temps de mise sur le marché ne posent pas de problème ? Qui, parmi nous, a un projet tout doux, tout rêveur, sans stress, où nous pouvons absorber en toute sécurité le terrible coût des tests unitaires ? Réponse : Les licornes et les lapins joyeux. Mais aucune personne que nous connaissons.

Par conséquent, la seule conclusion réelle de l’article de M. Fischer est que personne ne devrait jamais écrire de tests unitaires, quelle que soit leur utilité parfois, parce que le risque et le coût sont si élevés que vous devez justifier activement leur utilisation. (Remarquez qu’il ne semble pas y avoir de nécessité à justifier activement leur absence…)

M. Fischer n’a pas inversé LE BIT dans son esprit. Il pense toujours que les tests unitaires prennent du temps. Apparemment, il pense qu’ils prennent beaucoup de temps. Il pense toujours qu’il existe des situations dans lesquelles les tests unitaires ne sont pas utiles. Il n’a pas inversé LE BIT. Sur quelle planète vit-il ?

LE BIT
Qu’est-ce que LE BIT ? LE BIT est la variable booléenne dans notre subconscient qui représente notre croyance que les tests unitaires prennent du temps. Nous voulons que vous inversiez ce bit pour que votre croyance change. Nous voulons que vous croyiez que le développement piloté par les tests (TDD) fait gagner du temps dans tous les cas et dans toutes les situations, sans exception, amen.

Remarquez que nous n’avons pas dit : « Les tests unitaires font gagner du temps ». Nous avons dit : « Le TDD fait gagner du temps ». Nous pensons que c’est une distinction importante. Nous ne voulons pas que vous croyiez que les tests unitaires écrits a posteriori sont aussi bénéfiques que la discipline du TDD.

Voici le test pour LE BIT. Vous pouvez demander à un ami de vous poser ces questions. Si vous répondez comme indiqué ci-dessous, vous saurez que LE BIT a été flippé :

1. Avec une tâche, terminerez-vous plus rapidement en utilisant le TDD ? : OUI.
2. Y a-t-il des tâches que vous pouvez terminer plus rapidement sans utiliser le TDD ? : NON.
3. Je comprends que le TDD pourrait aider à long terme, mais que se passe-t-il si le travail est vraiment à court terme ? Utiliseriez-vous toujours le TDD ? : Oui, car le TDD est plus rapide, même à court terme.
4. Que se passe-t-il si le calendrier est très serré et que le patron vous met la pression, utiliseriez-vous toujours le TDD ? : OUI.
5. Dans tous les cas ? : OUI.
6. Y a-t-il un cas où vous n’utiliseriez pas le TDD ? : NON.
7. Que se passe-t-il si vous étiez à bord de l’Enterprise de Star Trek et que la bobine de distorsion était à quelques secondes d’une explosion d’antimatière et que tout ce que vous aviez à faire était d’inverser une déclaration IF pour sauver le vaisseau. Utiliseriez-vous le TDD pour cela ? : OUI.
8. Pourquoi ? : Parce que je terminerais plus rapidement.
9. Même pour une seule déclaration IF ? : Oui, même pour une seule déclaration IF.
10. Voulez-vous me dire qu’il n’y a aucun cas, absolument aucun cas, où vous n’utiliseriez pas le TDD ? : Eh bien, je pourrais ne pas utiliser le TDD si j’avais besoin que la tâche prenne vraiment beaucoup de temps à terminer et qu’elle comporte de nombreux bogues. Mais autrement ? Non, vraiment aucun cas.

C’est LE BIT. Lorsque vous avez inversé LE BIT dans votre esprit, alors, lorsque votre patron vous dit d’arrêter d’écrire des tests parce que vous n’avez pas le temps, vous refuserez et lui direz qu’il vous faudra plus de temps pour terminer sans le TDD – et vous le croirez ! Plus la pression est forte, plus vous vous appuierez sur la discipline du TDD.

Comment inversez-vous LE BIT ? Je peux vous dire comment j’ai inversé mon BIT. J’ai utilisé le TDD pendant un mois environ ; et mon BIT s’est inversé. C’est tout ce qu’il m’a fallu – juste le faire. Peut-être que cela vous suffira également. »

Ca fait réfléchir.