Le TDD pour Test Driven Development, ou encore développement piloté par les tests en français, est une méthode qui consiste à élaborer un logiciel en écrivant, avant chaque partie du code source, les tests qui lui correspondent. Peu intuitive de prime abord, l’approche TDD ne doit pas simplement être vue comme une façon de tester le code, mais comme une façon d’envisager les comportements attendus. C’est l’une des approches qui permet de mettre en œuvre la démarche plus générale du Software Craftsmanship, qui vise la qualité du code et l’excellence technique. Interview croisée de Nicolas Barlogis et Julien Vitte, coachs Software Craftsmanship, qui nous partagent leurs visions du TDD.
Pouvez-vous nous donner votre définition du Test Driven Development ?
NB – Dans de nombreux projets, les Users Story (US) fournies par le Product Owner (PO) ne sont pas toujours très claires. Un moyen de pallier ce problème est de commencer par écrire le test, car il permet de se focaliser sur l’objectif. En effet, commencer en se demandant « comment je vais utiliser ce que je vais produire » amène à questionner le PO, en lui demandant entre autres de fournir des exemples. Cela permet de mieux cadrer les attentes, et d’avoir une bien meilleure compréhension de ce qui doit être fait. Et très logiquement, la soutenabilité du code est améliorée, puisque le développeur ne va coder que ce qui répond à un usage précis.
JV – Le cycle TDD revient à d’abord écrire le test, et faire passer ce test le plus rapidement possible pour ensuite faire du refactoring. A mon sens cela correspond très bien à la vision Agile, car faire passer un test revient à dire j’ai apporté une nouvelle fonctionnalité, j’ai fait un incrément dans les possibilités du code le plus vite possible. Et à chaque incrément je peux livrer une nouvelle version de mon application. Je peux alors me poser la question est ce que mon code est bien écrit ? C’est donc un vrai booster pour obtenir de la qualité dans le code. Cette approche rejoint en cela la démarche Software Craftsmanship, et amène à des pratiques du clean code.
Pour en savoir plus sur notre parcours de formation dédié au Test Driven Development !
Justement, pouvez-vous nous donner votre vision de la démarche Craft ?
NB – A l’origine du manifeste Agile, les développeurs voulaient faire du code soutenable dans le temps. Ces principes de pérennité du code et d’entropie logicielle sont très importants. Car l’Agilité ne sert pas juste à savoir comment transitionner un chef de projet en PO. Mais cette vision d’origine s’est un peu perdue avec le temps, et l’apparition du software Craftsmanship a permis de retrouver cette démarche qualitative.
JV – Cette pratique Craft n’était pas clairement explicitée dans le manifeste d’origine, parce qu’à l’époque cela semblait évident. Aujourd’hui on peut avoir plusieurs interprétations du manifeste Agile. Pour moi la démarche Craft représente des valeurs, des principes, des pratiques qui amènent un véritable plus à l’agilité. L’approche TDD est un moyen de mettre en œuvre cette pratique.
Au-delà de la maintenabilité, le Test Driven Development sert également à mieux cibler le besoin ?
JV – Avec le TDD, la phrase « je vais avoir besoin de » n’existe pas. La bonne phrase est « j’ai besoin de ».
NB – L’énorme intérêt du TDD c’est ce design qui permet de se poser la question « de quoi j’ai besoin ». Pour ensuite ne faire que ce qui répond exactement à ce besoin. Cette démarche impacte d’ailleurs toute l’équipe, car j’ai vu des ateliers où le PO, à force d’être questionné, écrivait ses US de façon beaucoup plus précise, en y incluant des exemples. L’approche TDD ne concerne donc pas uniquement les développeurs.
JV – Cette démarche TDD donne aux développeurs des outils fonctionnels pour aller challenger le besoin fonctionnel. Et parfois savoir dire non et le justifier : je n’ai pas de jeu d’exemples, je ne connais pas exactement l’attendu, donc je ne peux pas coder de tests. Il existe des ateliers comme l’example mapping, qui se déroule lors de l’affinage d’une US, où le PO explicite les règles métiers qui sont cachées dans l’expression de l’US. Les intervenants viennent alors poser des exemples pour mettre en lumière de quoi le développeur va avoir besoin, ce qu’il va devoir faire, et quel est le résultat attendu. Il est d’ailleurs courant qu’à l’issue de ce type d’atelier une US soit scindée en deux parties. Une première est prioritaire et sera traitée dans le prochain sprint, et une autre dont le besoin est encore à affiner sera traitée ultérieurement comme une nouvelle US. De cette manière, on intègre les tests bien avant de commencer à coder, et les estimations sont plus fiables.
Quels sont vos conseils pour bien commencer une démarche Test Driven Development ?
JV – Souvent la pyramide de tests TDD est mal perçue. Il faut certes commencer par écrire des tests unitaires, mais il faut envisager ceux-ci par le « haut », par les besoins utilisateurs. Sinon les développeurs vont se retrouver à faire des tests purement techniques, pour des choses qui ne se produiront jamais. Ces tests n’ont donc aucune utilité, même s’ils sont parfaitement fonctionnels.
NB – Notre vision du TDD est très liée à l’approche behaviour-driven development (BDD), ou programmation pilotée par le comportement, puisque nous incitons les équipes à injecter du sens métier, et placer les mots du métier dans le code. Ce qui amène dans certains cas à ce que les tests d’acceptations, souvent écrits avec le langage Gherkin, soient directement rédigés par le PO.
JV – Il y a deux écoles TDD. La première est appelée Chicago et part du métier pour remonter et proposer des interfaces, et l’école London qui part du besoin utilisateur pour redescendre dans le code. Cette deuxième école a une approche outside-in, basée sur le besoin, qui fonctionne très bien avec le BDD.
NB – Et comme toujours faire beaucoup de katas, en commençant par des exercices très simples, et monter en complexité au fur et à mesure.
JV – Il est important de démarrer progressivement. La mise en place de TDD sur un code existant peut avoir un impact non négligeable sur le temps de développement. Se focaliser dans un premier temps sur des cas d’ajout de fonctionnalités maitrisées par l’équipe, ayant des règles métier explicites, est un bon début. Ou sur des cas de résolution de bugs, à condition que le code soit testable sans trop de complexité. Autre point à ne pas négliger : l’adhésion de l’équipe. Commencer le TDD seul peut se révéler plus difficile car le code produit par le reste de l’équipe pourrait rendre plus complexe l’apprentissage. Il faut commencer de manière collective, avec des sessions de pair ou mob programming pour obtenir un feedback rapide de la part de ses collègues. Définir des pratiques d’équipe est un facilitateur.
Avec le TDD, la phrase « je vais avoir besoin de » n’existe pas. La bonne phrase est « j’ai besoin de ».
Vous souhaitez échanger avec nos experts autour de vos enjeux et de la démarche Test Driven Development, c’est par ici !
