Test Driven Development (TDD) est l'une des pratiques au coeur de l'eXtreme Programming (bien que les idées autour du TDD soient plus anciennes que XP) et est considérée par beaucoup comme l'une des clés du développement de logiciels, pour délivrer des produits de meilleure qualité.
Récemment DHH (David Heinemeier Hansson), créateur de Ruby on Rails et fondateur de Basecamp, a donné la keynote d'ouverture de la Railsconf 2014 (vidéo disponible ici) dans laquelle il remet en question la valeur de TDD en l'état actuel de son implémentation.
Il a ensuite écrit deux articles plus détaillés intitulés “TDD is Dead – Long Live Testing” et “Test-induced design damage”.
Brian Oken a résumé les arguments de DHH dans les points suivants :
- Beaucoup de développeurs qui supportent TDD vous donnent le sentiment que votre code est sale si vous ne pratiquez pas de TDD.
- Diriger votre design du point de vue des tests unitaires n'est pas une bonne idée.
- La notion de TDD disant que "les tests doivent être rapides" est illusoire.
- Suivre TDD peut conduire à l'oubli total de tests plus globaux.
- L'accent mis sur les tests unitaires et uniquement unitaires n'aide pas à produire un bon système.
- Une couverture de 100% est ridicule et inutile.
- Les développeurs veulent que le logiciel soit une science, mais ce n'est pas le cas. C'est plus une écriture créative.
- Un bon logiciel n'est pas représenté par son ingénierie.
- Une écriture claire et concise vaut mieux qu'une écriture complexe.
- La clarté est importante. Tellement importante qu'elle devrait être le premier objectif visé, et non pas prioriser la couverture et la vitesse des tests.
- Être un bon développeur est aussi compliqué qu'être un bon écrivain.
- Comme pour l'écriture, pour être un bon développeur, il faut écrire et lire beaucoup de programmes.
La réaction a été importante dans la communauté (voir les tweets avec le hashtag #tddisdead) avec des positions différentes, allant du "bien entendu" au "c'est idiot".
Une grande partie des réponses traitaient de la nécessité d'appliquer de façon pragmatique TDD.
Uncle Bob Martin a répondu : Si vous ne pratiquez pas TDD, ou autre chose d'aussi efficace, alors vous devriez vous sentir mal.
Il continue :
Pourquoi pratiquer TDD ? Nous le faisons pour une raison primordiale et plusieurs autres moins importantes. Celles-ci sont :
- Passer moins de temps à faire du debug,
- Les tests s'apparentent à une documentation précise et non-ambiguë, au plus bas niveau du système.
- L'écriture des tests avant une implémentation nécessite un découplage, plus qu'avec d'autres stratégies de tests, et nous pensons qu'un tel découplage est bénéfique.
Ce sont des avantages auxiliaires de TDD, il est possible d'en débattre. En revanche, il y a un avantage qui, sous certaines conditions, ne peut être discutable :
Si vous avez une suite de tests à laquelle vous faites tellement confiance que vous pouvez déployer votre système lorsque les tests passent, et si cette suite peut être exécutée en quelques secondes, ou minutes, alors vous pouvez nettoyer et manipuler votre code sans craintes.
Martin Fowler a hébergé une série de conversations hangout entre DHH, Kent Beck (dont la réponse initiale se trouve ici) et lui-même pour analyser la pratique de TDD et son impact sur le design du logiciel.
Jusqu'ici, il y a eu 5 hangouts, dont le dernier a eu lieu le 4 juin, et consistait en une session de questions-réponses ouverte publiquement.
Martin Fowler a résumé les conversations de la manière suivante :
- Nous avons parlé de nos expériences variées de TDD, de sa logique de déroulement, et de la manière dont TDD et le code automatiquement testé peuvent être confus.
- David a le sentiment que TDD mène à l'emprunt de directions opposées au sein du code, ce qui est une conséquence des tests et de leur complexité. Kent pense que cela concerne plus la qualité des décisions de design que TDD.
- Nous avons discuté des différentes façons d'obtenir du feedback pendant le développement et le rôle de QA dans le retour qu'obtiennent les développeurs.
- Nous avons abordé certains effets négatifs du testing et de TDD : possibilité de faire trop de tests, et problème avec les équipes qui donnent plus d'importance à leurs tests qu'à leur code fonctionnel.
Gergely Brautigam a écrit un article intitulé “TDD is Dead – Not really” :
TDD n'est PAS MORT. C'est évident puisqu'il a tant de supporters, comment pourrait-il être mort ? C'est comme demander, les design patterns sont-ils morts ? Ou est-ce que l'automatisation de tests est morte ? Ou encore, les cookies Oreo sont-ils morts ?
Non, TDD n'est pas mort, ne le sera jamais. Il se changera peut-être en quelque chose de nouveau, quelque chose d'encore meilleur, mais il ne mourra jamais.
Il continue en parlant de l'importance des tests à des niveaux multiples et des raisons communes pour lesquelles les tests ne sont pas pratiqués de manière correcte dans certaines équipes de développement. Il mentionne un manque d'intérêt pour la qualité logicielle et la pression imposée aux développeurs liée aux contraintes de temps.
Il finit :
C'est mon expérience et mon opinion personnelle, ce que j'ai pu observer durant 10 ans de pratique de tests. Commencer avec au moins un squelette de projet et quelques tests aide sur le long terme. Ecrire un ou deux tests d'acceptation aide à mieux comprendre la logique métier. Ecrire un ou deux tests unitaires aide à former votre logique. Je ne dis pas qu'il faut écrire une suite complète de tests : il est compréhensible de ne pas vouloir en arriver à ce point, mais dans une optique de qualité, il faut en écrire au moins quelques uns.
Gil Zilberfeld conclut sur un conseil venant du manifeste Agile :
Nous découvrons de meilleures façons de développer des logiciels en pratiquant et en aidant d'autres à le faire.
Nous n'avons pas encore tout découvert. TDD est une pratique que l'on a découvert sur notre chemin, il y en aura d'autres.