Le TDD c'est génial mais personne n'en veut :(

Pour rappel, le Test-Driven Development (TDD ou développements pilotés par les tests), est une méthode de développement qui consiste à écrire le test avant d'écrire le code, de façon itérative. Les software craftsman (les artisans du logiciel) sont généralement des adeptes du TDD.

Les bénéfices sont nombreux et il y a beaucoup de littérature à ce sujet :

Guidage du développeur
Réponse stricte au besoin (moins d’entropie logicielle)
Complexité minimale
Filet de sécurité contre les régressions,
Meilleure qualité et moins de dette technique.
Documentation du code

Des études menées par Microsoft et IBM montrent qu’en moyenne :

Pour les projets TDD le développement initial est 25% plus long
Les projets TDD ont 70% moins d’anomalies que les projets classiques.

Alors pourquoi personne n’en veut ?

Pendant mes 15 ans de dev, j’ai essayé de « vendre » cette méthodologie à différents projets. On était tous d’accord que le TDD c’est bien et pourtant on n’en faisait pas.

J’ai analysé « le pourquoi » et voici mes conclusions personnelles :

Le produit

Certains logiciels ne se prêtent pas aux TDD. Le mock des interactions est tellement complexe et le coût serait énorme.

Ex: Linux n’utilise pas la méthodologie TDD pour les développements. Dans ce cas il faut mocker le matériel est cela peut être très compliqué.

Les développeurs

Le plus gros problème d’un développeur est le design émergent (emergent design) ou le design par le test.

Le développeur se concentre très souvent sur la fonctionnalité à développer sans se préoccuper de la testabilité de son code. Le jour ou on lui demande d’ajouter des tests unitaires il doit souvent casser (refactorer) son code pour le rendre testable. Le refactoring est souvent compliqué, car il fait mocker certaines interactions.

Le TDD impose au développeur de designer son code pour qu’il soit testable immédiatement. Autrement dit, le TDD sort le développeur de sa zone de confort.

D’autre part pour faire du code testable il faut un certain niveau d’expérience et compétences. Le TDD pour un parfait débutant risque de faire plus de mal au niveau de la qualité du code.

Le manager

Le chef de projet veille au respect du délai et des budgets. Justifier un prix 25% plus cher ou des délais 25% plus longs pour écrire du test c’est souvent très compliqué. On peut dire qu’en faisant du TDD la maintenance sera moindre, que le produit sera plus évolutif et que la productivité de l’équipe sera meilleure. Si le manager ne mesure (très souvent le cas) ces KPIs qualimetriques il ne peut pas justifier le choix du TDD.

Le client

Le client paye pour de la fonctionnalité pas pour des tests. Il se dit que c’est le job des IT de lui livrer un logiciel sans bug et de qualité.

Il faut former le client et lui expliquer l’intérêt du TDD, d’où l’importance de la proximité dev/management/client. On peut tout sacrifier, mais pas la qualité.

A mon avis, pour réussir à mettre en place le TDD dans une équipe il faut :

Des développeurs compétents et expérimentés
Un chef de projet mature qui comprend les enjeux et peut les transmettre au client
Un client ouvert d’esprit et qui fait confiance à ses développeurs