L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Le Développement Dirigé par les Tests est une des pratiques emblématiques d'Extreme Programming. A ce titre, elle est devenue un passage presque obligé pour quiconque envisage d'évoluer vers les méthodes agiles.

Le problème avec les pratiques disruptives, c'est que, lorsqu'elles viennent s'insérer dans un contexte existant, leur mise en oeuvre peut souffrir d'approximations. Les méthodes agiles font face, bien plus que d'autres, à ce genre de mésaventures : la faiblesse dans la prise en compte des pratiques d'ingénierie est une réalité.

Vendredi dernier j'assistais à la 9ème édition des séminaires SIGMAT. Une bonne cuvée comme en attestent les compte-rendus d'Antoine ou de Laurent.
Sur la présentation d'Atchick Realtime, un paragraphe a retenu mon attention :

TDD (pour les tests manuels) à Toulouse (2 testeurs), pas de testeur à CPH => pas de TDD au sens des tests manuels. Sur les deux sites : tests unitaires

Pour quiconque ayant déjà expérimenté le TDD, cette formulation a de quoi laisser perplexe. Renseignement pris auprès des personnes concernées, leur pratique consiste, au sein d'une itération, en :

• l'écriture de fiches de tests par les testeurs avant que le code correspondant soit écrit
• l'écriture du code
• la vérification par le test prévu

Rien à redire à ce genre de pratiques. Il est toujours préférable que l'on sache comment vérifier du code avant de l'écrire. Cela améliore le feedback sur le produit développé et la communication entre ceux qui savent ce que le logiciel doit faire et ceux qui l'écrivent.
Rien à redire à ce genre de pratiques, si ce n'est que ce n'est pas du TDD.

Alors, bien sûr, en écrivant les tests avant le code, on peut dire que le développement est piloté par les tests. Oui mais à ce compte là, le cycle en V est lui aussi piloté par les tests puisque les tests sont écrits dans la descente du V, avant l'écriture du code, et joués lors de la remontée du V.
Ce qu'il ne faut pas oublier, c'est que l'apport principal d'Extreme Programming, c'est d'avoir poussé à l'extrême des pratiques existantes. En l'occurrence, le TDD, c'est la contraction dans un laps de temps le plus court possible de ces phases "écriture de test-écriture du code correspondant-vérification du test". En pratique, ce genre de cycle est exécuté plusieurs fois par heure.

Pour rendre cette contraction possible, il faut s'affranchir de quelques contraintes. Une communication trop formalisée entre un testeur et un codeur ne permettrait pas de maintenir le rythme. La seule solution pour pratiquer le TDD c'est de mettre devant le même écran la ou les personnes qui vont faire fonctionner ces cycles de test-codage à haute fréquence.
Le corollaire de cette approche, c'est que le codeur et le testeur sont bien souvent obligés d'être des rôles tenus par les mêmes personnes : des développeurs, au sens le plus large possible du terme.

Pour être compris, le TDD souffre d'un grand handicap : la lettre T comme "Test". Le TDD n'est pas une pratique de test. Le TDD n'est pas une pratique de test. Le TDD n'est pas une pratique de test. (quelquefois c'est en répétant plusieurs fois les choses que l'on arrive à s'en souvenir). Le TDD est une pratique de développement logiciel, c'est à dire de conception d'un produit à partir de contraintes.
C'est une des raisons qui font que je préfère désormais le terme BDD à celui de TDD.

Ceci étant, deux sortes de TDD vont encore cohabiter pendant longtemps : celle de ceux qui l'ont compris et celle de ceux qui ne l'on pas encore compris.