TDD : une discipline de design, pas de test

L’une des méprises les plus tenaces concernant le Test-Driven Development est de le réduire à une technique pour écrire des tests.

Le nom même induit en erreur : on entend « test » et on pense vérification, couverture, assurance qualité. Or Kent Beck , son créateur, n’a cessé de le répéter : TDD est une technique de design, pas de test. Les tests ne sont qu’un sous-produit (“byproduct”), certes précieux, d’un processus dont la finalité première est de guider l’émergence d’une architecture logicielle.

Confondre TDD avec une stratégie de test, c’est confondre l’échafaudage avec le bâtiment.

Le cycle rouge-vert-refactor

Le cycle rouge-vert-refactor incarne cette orientation vers le design.

Phase rouge : l’interface d’abord

La phase rouge, écrire un test qui échoue, force à réfléchir à l’interface avant l’implémentation :

• Comment vais-je appeler ce code ?
• Quelles données dois-je lui fournir ?
• Que dois-je obtenir en retour ?

Ces questions, posées du point de vue du consommateur du code, produisent naturellement des API plus ergonomiques que celles conçues depuis l’intérieur de l’implémentation. On ne demande pas « comment vais-je structurer mes données internes ? » mais « comment mon collaborateur veut-il interagir avec ce module ? ».

Le test devient un premier client exigeant qui façonne l’interface publique.

Phase verte : résister à l’over-engineering

La phase verte (faire passer le test le plus simplement possible) semble naïve mais sert un objectif précis : résister à la tentation de l’over-engineering.

On n’implémente que ce qui est nécessaire pour satisfaire le comportement spécifié. Pas de généralisation prématurée, pas d’abstraction spéculative. Le code reste minimal, ancré dans des besoins concrets.

Phase refactor : l’émergence des patterns

C’est la phase refactor qui, ensuite, permet de restructurer (extraire des fonctions, introduire des abstractions, éliminer les duplications) mais seulement quand les patterns deviennent visibles à travers plusieurs tests.

Le design émerge de l’accumulation de cas concrets plutôt que d’être imposé a priori.

L’émergence comme philosophie

Cette émergence constitue le cœur philosophique de TDD.

Plutôt que de concevoir une architecture en chambre, de dessiner des diagrammes UML, puis d’implémenter ce plan préétabli, on laisse la structure se révéler test après test.

Chaque nouveau test exerce une pression sur le design existant : si le test est difficile à écrire, c’est un signal que le code testé est mal découplé, que ses responsabilités sont confuses, que ses dépendances sont trop rigides. La difficulté du test devient un feedback immédiat sur la qualité du design.

Les développeurs expérimentés en TDD reconnaissent ces frictions et les utilisent comme boussole pour guider leurs refactorings.

Les tests comme trace fossile

Les tests qui résultent de ce processus ont une qualité particulière : ils documentent le comportement attendu plutôt que l’implémentation interne. Ils forment une spécification exécutable du système, exprimée en termes de cas d’usage concrets.

Mais leur valeur première reste celle qu’ils ont eue pendant le développement : servir de levier pour un design découplé, cohésif, et adapté aux besoins réels.

Une suite de tests écrite après coup peut vérifier le même comportement, mais elle n’aura pas exercé cette pression formatrice sur l’architecture. TDD ne produit pas de meilleurs tests ; il produit un meilleur design, dont les tests sont la trace fossile.