TDD est une pratique de moins en moins controversée, mais qui a toujours du mal, comme toute pratique contre-intuitive, à réellement devenir dominante et maitrisée. Même parmi les personnes qui s’y sont essayées, nous trouvons des réfractaires, et bien souvent, leur argument principal ressemble à ça :
Oui le TDD, on a essayé, mais ça coûte cher. Les tests sont longs à écrire et à maintenir, et finalement ils se cassent au moindre refactoring. Du coup nous : faisons surtout des tests d’intégration, ne testons pas tout, ne faisons pas de refactoring (rayez la mention inutile).
Quand on observe les tests qui ont été produits, ils sont souvent effectivement compliqués et fragiles. En creusant un peu, et en comparant les situations, nous arrivons pratiquement invariablement à la même conclusion: les personnes qui tiennent ce discours sont passées à côté du secret du TDD; du changement d’état d’esprit qu’il implique, et dont tout le reste découle. C’est ce changement de point de vue, ce passage à un autre paradigme, qui permet de faire apparaître et évoluer le design, comme TDD le promet; qui permet d’obtenir des tests rapides, facile à comprendre, qui sont une aide au refactoring; qui permet de voir des sourires et de la fierté au sein d’une équipe sûr de son travail. Quel est donc ce changement fondamental ?
Il ne faut pas penser à l’implémentation en écrivant son test
Voilà, c’est tout simple. Systématiquement, les syndromes évoqués plus haut sont issus d’une volonté de prouver une implémentation plutôt qu’une fonctionnalité. Ce faisant, le test va avoir tendance à couvrir trop de terrains, s’appuyer intensivement sur les mocks, et à ne porter aucunement une intention compréhensible, et donc maintenable. En voulant sauter des étapes, aller directement à l’implémentation que nous imaginons, nous perdons en fait tous les gains de productivité attendus.
Vous pouvez savoir si vous souffrez de ce syndrome si :
- vous ne comprenez plus vos tests,
- vous passez systématiquement plus de 10 minutes à écrire un test
- vos tests sont longs (en terme de lignes),
- vos tests sont longs (en terme de temps),
- vous avez des tests dont le nom est seulement la méthode qu’ils appellent,
- vous êtes tenté après coup de rendre des méthodes qui étaient privées, publiques,
- le moindre refactoring fait hurler plusieurs tests (nous rappelons que le refactoring est le fait de changer la structure interne du code sans changer son comportement extérieur)
Pour «attraper le coup», il n’y pas de secret. Il faut s’entrainer, avec des katas, à suivre ces 3 règles :
- Nous n’avons pas le droit d’écrire de code de production pour autre chose que faire passer un test au vert
- Nous n’écrivons pas plus de code de test que nécessaire pour qu’il soit rouge, et la compilation qui ne passe pas est un test rouge
- Nous n’écrivons pas plus de code de production que nécessaire pour faire passer un test au vert
Vous pouvez bien sur aussi vous inspirez de démonstrations de praticiens expérimentés, comme ce nombre romain en javascript.
Une fois que vous aurez «pigé le truc», c’est à ce moment là que le TDD ne vous apparaitra plus comme une contrainte, mais comme une pratique libératrice de votre code, de vos capacités, et de votre plaisir à développer.