Publié par
Il y a 4 mois · 4 minutes · Agile, Craft

A la découverte de l’ATDD – une pratique d’équipe pour le développement 1/3

Je vous propose dans ce qui sera une série de 3 articles, de découvrir l’ATDD à travers un cas concret. Les tutoriels sur l’ATDD ne manquent pas mais ils occultent bien souvent l’aspect collaboratif en ne mettant pas en évidence en quoi l’ATDD modifie le flux de travail et la dynamique de l’équipe, pour se concentrer sur la technique.

L’ATDD c’est quoi ?

L’ATDD, ou Acceptance Test-Driven Development consiste à guider l’implémentation d’une fonctionnalité à travers ses tests d’acceptation. On écrit d’abord le test d’acceptation, on constate qu’il échoue, puis on implémente la fonctionnalité, juste assez pour que le test passe.

Vous aurez tout de suite remarqué la similitude avec le « TDD » (Test Driven Development), mais les différences entre ces deux pratiques sont réelles. La première différence fondamentale est que le TDD est une pratique de programmeur, alors que l’ATDD est une pratique d’équipe. Nous verrons pourquoi dans un instant. La deuxième différence est que le TDD aide à prouver au programmeur que son code fait ce qu’il aimerait qu’il fasse, alors que l’ATDD aide à prouver à tout le monde que le produit fait ce que le client aimerait qu’il fasse.

Autre membre de la famille « DD », le BDD (pour Behavior-Driven Development) est une démarche proche de l’ATDD, mais qui met l’accent sur la collaboration avec le client. Cela se traduit concrètement par l’utilisation systématique d’un langage compréhensible du client (on parle de « domain specific language ») dans l’écriture des tests; là où avec l’ATDD, le langage peut rester celui de l’équipe de développement.

Dans la pratique il est fréquent que ces pratiques se recoupent; et les équipes agiles naviguent de l’une à l’autre sans trop se poser de questions.

Les protagonistes

Nous serrons accompagnés dans ce tutoriel de 3 protagonistes : Aurore, développeur; Nicolas, testeur, qui font partie de la même équipe Scrum; ainsi qu’Héloïse, leur Product Owner. Nicolas est à l’initiative de la démarche d’ATDD dans l’équipe et il s’est donné pour mission de coacher ses collègues dans l’adoption de cette pratique ! Il n’est lui-même pas un expert de la démarche, et il y a fort à parier qu’il tombera dans quelques pièges …

La User Story

L’équipe travaille au développement d’un site web pour une pizzeria qui livre à domicile, dans Paris.

Héloïse soumet à l’équipe la première User Story :

ATDD

Spécification par l’exemple

Dans une démarche d’ATDD, l’équipe commence par rédiger les tests d’acceptation associés à la User Story.

Cela peut être fait lors d’une réunion type « Backlog Refinement Meeting » ou « Backlog Grooming ». Avec toute l’équipe, ou en plus petit comité, en général à 3 : le Product Owner, un testeur et un développeur.

En l’occurrence, Héloïse, Aurore et Nicolas se sont simplement réunis tous les 3, quelques jours avant le prochain Sprint Planning et se sont donnés 15 minutes pour rédiger les cas de tests. La micro-réunion commence :

 

PAGE 1

 

ATDD-BD1

 

PAGE 2

 

ATDD-BD2

 

PAGE 3

 

ATDD-BD3Voilà ! En 10 minutes chrono, Aurore, Héloïse et Nicolas ont finis de « spécifier par l’exemple » cette User Story. Aurore s’est évité un joli bug sur la méthode de calcul, et Héloïse a retenu que parfois, un exemple valait mieux qu’un long discours. Les 3 collègues mettent donc la User Story de côté pour le moment, et jusqu’au prochain sprint.

La spécification par l’exemple peut aussi avoir lieu plus tard. Dès que la User Story commence par exemple. Plus on fait l’exercice tôt, plus il y a un risque de devoir y revenir, voire de gâchis pur et simple si les priorités changent du tout au tout et que la User Story se retrouve écartée. A l’inverse, en la faisant au dernier moment, vous acceptez de découvrir plus de choses en cours de Sprint, et donc, notamment, d’avoir des estimations un peu moins fiables. A vous de trouver ce qui fonctionne le mieux dans votre équipe !

Dans le prochain article, nous rentrerons dans le vif du sujet et suivrons Nicolas et Aurore, qui ensemble réaliseront leur première User Story en commençant par l’automatisation des tests d’acceptation.

A suivre …

Grégory FONTAINE
Grégory a 10 ans d'expérience au cours desquels il a été Chef de Projet puis Responsable Qualité avant de se trouver une passion pour l'agilité et de devenir Scrum Master et Coach. Développeur sur son temps libre, Grégory aime aussi bien accompagner des équipes de développement dans l'implémentation de pratiques d'ingénierie que travailler sur des transformations organisationnelles à grande échelle.

5 réflexions au sujet de « A la découverte de l’ATDD – une pratique d’équipe pour le développement 1/3 »

  1. Publié par Greg Hutchings, Il y a 4 mois

    Merci, Gregory, c’est un excellent introduction a SBE et A-TDD, que je partagerai avec mon client. J’aime bien la façon d’introduire le processus SBE avec les personnages ludiques et naturelles qui exprime les doutes et confusions en fin d’etre convaincu par les exemples concrets.

    J’attends avec hate les episodes 2 et 3!

  2. Publié par joeclueless, Il y a 4 mois

    Bonjour

    Merci beaucoup pour cet article. Quelques remarques :
    – je préfère perso le terme « spécifications par l’exemple » qu’ATDD. Il me paraît en effet bien plus clair pour tout le monde
    – nous utilisons http://concordion.org/ pour mettre en oeuvre ce que vous présentez : allez vous aussi partir dessus ? A défaut je suis preneur des raisons de ce non choix. Personnellement je trouve que concordion a, par rapport à Gauge ou FITness, les avantages d’être : léger, intégré à Junit, juste une librairie, permettre le html, embarqué dans le code du projet (dans les tests) et donc dans git.

    Au plaisir de vous lire !

    ++

  3. Publié par Grégory FONTAINE, Il y a 4 mois

    @Greg merci ! les articles 2 et 3 arrivent première semaine de janvier et sont plus riches encore que celui-ci à mon avis !

    @joeclueless en faisant relire cette article par des collègues et à la lecture de votre commentaire aussi, je constate comme un « joyeux bordel » autour de la terminologie. Personnellement j’ai choisi d’utiliser le terme ATDD car c’est le terme utilisé dans le livre qui m’a initié à cette pratique (https://www.amazon.com/ATDD-Example-Test-Driven-Development-Addison-Wesley/dp/0321784154), mais « spécifications par l’exemple » j’aime bien aussi :)
    Dans les articles suivants, nous allons utiliser Behat, sur du PHP.
    Concordion a l’air top effectivement mais je ne l’ai jamais utilisé !
    a+

  4. Publié par joeclueless, Il y a 4 mois

    Merci pour cette réponse Grégory.

    Pour le terme Spécifications par l’exemple, il est beaucoup utilisé par concordion et il existe un livre du même nom https://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084/ref=sr_1_1?s=books&ie=UTF8&qid=1483019063&sr=1-1&keywords=Specifications+by+example (je ne le recommande pas). J’aime surtout la clarté du terme au final.

    D’ailleurs en termes de terminologie on voit aussi « User Acceptance Testing » (UAT). Et dans l’absolu le Behavior Driven Development (BDD) est à peu près la même chose, en moins bien AMHA.

    A propos, « ATDD by Example: A Practical Guide to Acceptance Test-Driven Development » vaut il le coup ?

    Encore merci

    ++

  5. Publié par Grégory FONTAINE, Il y a 4 mois

    Oui c’est un bon bouquin. Mais je le recommanderais surtout à des gens qui débutent ou qui ont essayé l’ATDD mais ont le sentiment de mal s’y prendre, de ne pas en tirer les bénéfices attendus…

  6. Publié par Boudali, Il y a 3 mois

    Article intéressant, merci

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *