Développement piloté par les tests - 5 idées reçues

La méthode du développement piloté par les tests (Test Driven Development, TDD) dit d'écrire les tests unitaires en même temps que le code. On répète le cycle suivant :

• Écriture d'un test unitaire, alors que le code testé n'existe pas encore.
• Exécution du test. Il doit échouer.
• Écriture du code.
• Exécution du test. Cette fois-ci il doit passer.

J'ai expérimenté le développement piloté par les tests il y a quelques années avec l'outil emblématique de cette pratique, JUnit. Je suis depuis un inconditionnel, que ça soit en Java ou en Ruby on Rails. J'ai naturellement essayé de convertir mon entourage au TDD. L'évangéliste occasionnel que je suis a été confronté à quelques préjugés. Parfois fausses ou plus souvent exagérées, il convient de démonter les idées préconçues.

1. Ce n'est pas mon travail

Une réaction bien naturelle lorsqu'on travaille dans une équipe qui compte des testeurs. Si un développeur écrit des tests, ne fait-il pas le travail d'un autre ? N'est-il pas en train de se disperser ? Pas du tout.

Il est entendu qu'un développeur commet des erreurs. On les retrouvera sous la forme de bugs dans le code. Cependant, il y a aussi une qualité minimale qu'on attend du développeur. D'abord, le code doit compiler. On imagine mal un développeur qui livrerait à ses collègues un code contenant des erreurs de syntaxe. Et puis, bien que ça ne soit pas la règle dans toutes les sociétés, le code doit fonctionner. On ne parle pas d'un fonctionnement qui satisfasse toutes les parties prenantes, ce sont les testeurs qui s'en assureront. Mais de quelque chose "qui tourne".

C'est le premier objectif du TDD. Écrire un code qui marche. Plus précisément, un code conforme aux intentions du développeur. Ne vous inquiétez pas pour les testeurs, ils devront toujours vérifier que le logiciel est conforme aux exigences, qu'il est robuste, performant...

2. Tester prend du temps

Le calcul est vite fait. Avec le TDD, on écrit le code et les tests. Sans, on se contente du code. Alors, le TDD prend plus de temps ? Sans doute, mais beaucoup moins qu'on pourrait le penser.

En réalité, on se contente rarement d'écrire du code puisque, on l'a vu, on veut s'assurer qu'il fonctionne. La méthode la plus primaire, mais tellement naturelle, consiste à exécuter le code à la main. Le développeur lance le programme qu'il écrit et interagit pour en vérifier le comportement. Dans le cas d'une librairie, il ira même jusqu'à écrire un petit programme qui l'utilise. Simple.

Ces essais prennent du temps, surtout lorsque la portion de code à tester est difficile à atteindre. Par exemple, si on essaie l'achat sur un site de e-commerce, il faut à chaque fois ajouter des éléments au panier, entrer un nom et une adresse postale, etc. Espérons qu'il n'y ait pas trop de bugs !

Alors oui, le TDD prend du temps, mais il convient de faire ses comptes en considérant tous les paramètres.

3. Tester ou faire des essais, ça revient au même

Écrire un test ou faire des essais, deux façons de parvenir au même résultat : un programme qui se comporte correctement. Dans un premier temps c'est vrai, mais à plus long terme il y a une grande différence.

Les essais sont vites oubliés. Lorsqu'on écrit un programme pour tester une librairie, on n'a généralement aucune velléité de réutilisation. Pas de commentaires, un code sans structure réfléchie, des "print" ça et là pour que le résultat soit visuel... Dès que le développement est fini, tout cela est jeté.

Les tests unitaires, eux, sont là pour rester. Les méthodes agiles s'en servent de suites de non-régression, indispensables lors des épisodes de refactoring. Quel que soit le cycle de développement, on trouve de nombreuses utilités aux tests unitaires écrits des mois auparavant.

4. Tester est ennuyeux

Le test a parfois mauvaise presse. Rappelons d'abord qu'en TDD, on parle de tests automatisés, et non de tests manuels. Cela est donc moins pénible et intellectuellement plus satisfaisant.

Une fois de plus, les tests sont à comparer aux essais auxquels on devra se livrer en leur absence. Faire des essais peut être très simple, ce qui constitue un avantage. En dehors de ce scénario qui se produit trop rarement, faire des essais lasse rapidement.

Les tests unitaires quant à eux sont de vrais programmes, destinés à être conservés et écrits dans les règles de l'art. En ce sens, ils apportent la même satisfaction que le code bien architecturé, indenté et commenté. Parfait pour contenter les perfectionnistes que nous sommes souvent.

5. Tester ne paie qu'à moyen terme

Un de ces jours, les tests serviront de suite de non-régression. Mais là, maintenant, tout de suite, il y a du code à écrire et les tests ne servent à rien. Autant coder sans interruption et faire un seul essai final.

Il me semble que les pratiques du développement n'évoluent pas dans ce sens. Ces dernières années ont vu la fin des erreurs de compilation... pour certains langages en tout cas. Autrefois, les éditeurs de code ne proposaient qu'une coloration syntaxique rudimentaire et chaque compilation venait avec son lot de surprises : une parenthèse manquante par ci, une faute de frappe par là. On pouvait consacrer une partie de sa journée à corriger ces erreurs. Des IDE comme Eclipse se sont depuis imposés et les éditeurs de quelques langages comme Java sont évolués au point que chaque erreur de compilation est signalée sitôt commise. Les corrections interviennent au fur et à mesure et la compilation est désormais une formalité.

Ce que les IDE ont fait pour la compilation, le TDD le fait pour le fonctionnement. Bien sûr, on commet toujours les même bugs, mais ceux-ci sont détectés et corrigés sur le champ. On a le sentiment d'écrire du code qui marche du premier coup, ce qui est très appréciable. Inutile d'attendre pour bénéficier des tests, ils paient immédiatement.

Et aussi...

L'énumération de ces idées reçues est l'occasion d'évoquer des avantages du développement piloté par les tests : constitution d'une suite de test, satisfaction du travail réalisé... Le TDD a également d'autres atouts, comme celui de concevoir du code testable dès le départ. On se surprend souvent à concevoir du code mieux structuré et moins monolithique justement parce que le test correspondant semblait trop difficile à écrire de prime abord.

Il existe de nombreuses ressources sur le Web à ce sujet et quelques ouvrages. À vous de jouer, à vous de convaincre vos collègues !