Cet article résume l'expérience d'un professeur d'université qui a abandonné le TDD, ainsi que les objections d'Oncle Bob sur ses arguments.
Ian Sommerville est un professeur d'ingénierie logiciel à la retraite, ayant écrit plusieurs livres dont Software Engineering, 10th edition. Le chapitre 8 de ce livre est dédié aux Tests Logiciel, et le sous-chapitre 8.2 au TDD en particulier. Reprenant certaines idées de ces chapitres, Sommerville a déclaré dans un billet récent “TDD est un pas important en avant en ingéniérie logiciel. Il y a des classes de système qui en bénéficient clairement”, listant les systèmes “TDD-friendly” suivants :
- Une architecture en couches
- Un système avec des critères de succès partagés, en construisant les tests autour de ces critères
- Un environnement opérationnel contrôlable, sans interaction avec d'autres systèmes hors de son contrôle (ce qui s'appelle un système simple et autonome - NdT).
Le TDD marche bien pour de tels systèmes, d'après Sommerville, mais il trouve qu'il est compliqué de l'utiliser pour d'autres types de systèmes :
J'ai commencé le TDD dans un cours de système avec ces critères, et j'ai aimé ça. Cela a bien marché pour moi. Puis, j'ai démarré sur des systèmes utilisant des structures de visualisation de liens complexes. La chose avec la visualisation, c'est que (a) il est souvent plus difficile d'avoir des couches séparées - l'interface est le programme et (b) il est très difficile d'avoir des critères de succès prédéfinis - vous devez essentiellement développer en expérimentant et voir ce qui marche et ne marche pas. Le TDD ne marche pas.
Sommerville a également écrit le billet Abandonner le développement en testant d'abord, dans lequel il partage son expérience TDD sur un projet personnel. S'il trouvait le TDD utile au début, en commençant à travailler sur les IHM, il se rendit compte qu'écrire des tests devenait plus dur et il ne pense pas que le temps passé à rédiger des tests était bien dépensé. En conclusion, il a fini par rédiger l'implémentation de code avec les tests et les ajoutait plus tard. Finalement il abandonna le TDD, et s'en explique :
Je n'abandonne pas le TDD du fait des difficultés (bien connues) pour écrire des tests automatisés pour les IHM. J'abandonne parce que je pense qu'il encourage le conservatisme dans le développement. Cela vous encourage à prendre des décisions de design qui peuvent être testées, plus que de prendre de bonnes décisions pour les utilisateurs. Cela pousse à se concentrer sur les détails, plus que sur la structure. Et cela ne marche pas bien pour la majorité des classes de problèmes - ceux venant de données non attendues.
Sommerville détaille encore :
- Le TDD encourage le conservatisme : on est moins enclin à réaliser des changements majeurs à une application sachant que cela cassera de nombreux tests qu'il faudra réécrire.
- "Parfois, le meilleur design est celui qui est difficile à tester".
- Le TDD met le focal sur le détail plus que sur le tout. "Avec le TDD, vous plongez dans le détail des différentes parties du programme et prenez rarement du recul pour la vision globale."
- Il est difficile d'écrire des tests sur des données non prédictibles.
Dès lors, il a décidé d'écrire le code d'abord, les tests ensuite. Mais ce billet n'est pas passé inaperçu. Robert C. Martin, connu sous le nom d'Oncle Bob, a mis son poids pour réfuter les arguments de Sommerville sur l'abandon du TDD. Oncle Bob pense que Sommerville a rencontré les difficultés des débutants et a abandonné trop tôt. La raison pour laquelle les changements d'un composant du système cassent constamment un autre composant est que les deux sont trop fortement couplés. Quand quelqu'un a peur de refactorer le code parce qu'il casse les tests, cela signifie que les tests sont trop couplés avec le code produit. Il faudrait organiser le système en couches indépendantes, et chacune devrait donner un accès par des interfaces, celles-ci étant aussi utilisées dans les tests.
Oncle Bob a balayé l'idée que "le meilleur design est celui qui est difficile à tester", la considérant comme stupide. Un design qui ne peut être testé ne marchera probablement pas quand il le faudra. Pour les situations difficiles, comme tester une IHM ou un driver, il mentionne le pattern de la Humble Dialog Box comme option.
Oncle Bob n'est pas non plus d'accord sur le focus dans le détail du TDD. Il explique qu'un développeur devrait toujours construire un design :
Peu importe ce que vous écrivez ; que ce soit du test unitaire, d'acceptation, ou du code, ou du mock, stub, vous devez DESIGNER...
Nous sommes des développeurs! Nous faisons du design! Nous créons des structures avec une cohésion forte et un couplage faible. Nous gérons les dépendances. Nous isolons les modules. NOUS DESIGNONS.
Oncle Bob continue en rappelant que, parfois, les développeurs oublient le design. En particulier les débutants, dans n'importe quel domaine, ont tendance à se concentrer sur un certain bas niveau de détails parce qu'ils sont dans un processus d'apprentissage. Il souligne l'importance de garder à l'esprit la vision globale en rappelant le conseil de Ron Jeffries - co-auteur de XP et signataire du Manifeste Agile - : "Agissez localement. Pensez Globalement."
Enfin, Oncle Bob accepte qu'il est difficile de gérer les cas inattendus, mais ce n'est pas du fait du TDD :
Apollo 1 a pris feu. Apollo 13 a explosé à mi-parcours de la Lune. Challenger s'écrasa juste après le lancement. Columbia se désintégra en rentrant. Pourquoi ? Parce que malgré des milliers de cerveaux essayant de penser à tout, l'imprévisible est survenu...
Faîtes avec. Il y aura toujours un risque. Ne jetez pas la faute sur le TDD, et n'abandonnez pas.
Israel Fermin Montilla, Ingénieur Logiciel, a tenté une conciliation en commentant le billet de Sommerville :
Je pense que le sujet autour de l'écriture des tests n'est pas de les écrire avant ou après, c'est juste de les écrire et d'avoir la discipline pour les maintenir et de rester strict sur la couverture de code attendue sur un projet. Les écrire d'abord a des avantages certains, mais c'est une technique qui peut ne pas marcher pour tous ou pour tous les projets. D'après mon expérience, il y a toujours des contraintes de temps qui poussent à implémenter plus vite et à ne tester que les points critiques. J'ai travaillé dans des Startups et des entreprises du web, donc dans des environnements à changements rapides/orientés marketing. Parfois, vous augmentez la dette technique (surtout dans les Startups au démarrage) pour le besoin de la livraison et le retour de données pour une évaluation.