Voir la source de BDD en bref

[[Category: Portail Product Owner]]
[[Category: Portail Equipe de développement]]
[[Category: Tests]]
[[Category: BDD]]
[[Catégorie:Rachel Davies]]
Auteur : Rachel Davies<br/>
Source : [https://agilecoach.typepad.com/agile-coaching/2012/03/bdd-in-a-nutshell.html BDD in a Nutshell]<br/>
Date : 10/03/2012<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 04/04/2019<br/>
----
Traduction :<br/>
<br/>
Vendredi, j'ai discuté avec Katie, elle travaille dans un département où les équipes essaient d'appliquer le développement piloté par le comportement (BDD). Elle n'a pas encore participé à l'atelier de formation de [http://blog.mattwynne.net/ Matt Wynne] sur le BDD et elle cherche des articles sur le sujet pour expliquer de quoi il s'agit. J'ai donc rédigé ce billet pour expliquer ce qu'est le BDD et rassembler quelques liens pour en savoir plus.<br/>
==Qu'est-ce que BDD ?==
Le B dans BDD signifie ''Behaviour'', le ''comportement'' souhaité du logiciel à développer. La partie DD est l'abréviation de ''Driven-Development'' (piloté par le comportement). BDD est une approche pour construire une compréhension commune sur le logiciel à construire en travaillant sur des exemples.<br/>
<br/>
J'ai dessiné ce schéma de base pour illustrer l'idée de base.<br/>
<br/>
[[Fichier:BDD-is-share-understanding.jpg|border|link=]]<br/>
<br/>
BDD est assez simple, décrivez ce que vous voulez que le système fasse en donnant des exemples de comportement. Travaillez de l'extérieur vers l'intérieur pour mettre en oeuvre ces comportements en utilisant les exemples pour valider ce que vous êtes en train de construire.<br/>
<br/>
Il n'est pas nécessaire de réunir toute l'équipe, mais il est utile d'avoir différentes perspectives pour étoffer les exemples. Le client (qui peut être un Scrum Product Owner) décrit ce qu'il veut et les développeurs posent des questions afin de disposer de suffisamment de détails sur le comportement pour pouvoir le mettre en oeuvre. Si vous avez des analystes métiers (BA) ou des spécialistes de l'assurance qualité (QA), ils peuvent vous aider à faire émerger les détails des différents scénarios.<br/>

==Comme TDD mais encore plus==
Les exemples sont souvent transformés en tests automatisés et la pratique du BDD suit la même idée de base que le développement piloté par les tests d'acceptation (ATDD), où les tests d'acceptation sont élaborés pour chaque user story et automatisés à mesure que le logiciel est construit. Matt Wynne dit : ''"Le BDD est en fait du TDD réalisé correctement."''<br/>
<br/>
BDD est '''plus que du TDD''' parce qu'il met l'accent sur la collaboration avec les gens du métier. [https://dannorth.net/ Dan North], à l'origine du surnom BDD, avait remarqué que les gens du métier restaient silencieux dans les conversations sur les "tests" car ceux-ci semblaient trop techniques. Il espérait que le fait de structurer les conversations autour des "comportements" attendus serait un moyen d'impliquer l'équipe entière.<br/>

==Langage universel==
Pour s'assurer que toute l'équipe comprenne ce que l'on veut, nous décrivons le comportement dans un langage non technique. Nous prenons soin d'utiliser des noms qui reflètent le ''langage universel'' utilisé par les gens du métier, un des principes de base du [https://www.amazon.com/exec/obidos/ASIN/0321125215/ Domain-Driven Design] (Conception pilotée par le domaine) expliqué par Eric Evans et résumé dans [https://www.infoq.com/minibooks/domain-driven-design-quickly Domain-Driven Design Quickly].<br/>
<br/>
En fin de compte BDD consiste à construire une compréhension commune, '''vous faites mal du BDD si les seules personnes qui lisent les exemples sont les développeurs'''. J'ai l'impression d'avoir vu cette mise en oeuvre de BDD dans quelques endroits, regardez l'image ci-dessous. BDD est bien plus qu'un moyen d'automatiser les tests et si c'est tout ce que vous avez à l'esprit, un framework de tests unitaires pourrait vous donner une batterie de tests plus rapides.<br/>
<br/>
[[Fichier:Examples-what-if.jpg|border|link=]]<br/>
<br/>

==Inspirations de BDD==
BDD trouve ses origines chez les praticiens de [http://wiki.c2.com/?ExtremeProgramming l'eXtreme Programming] (XP) qui cherchaient un moyen d'impliquer toutes les perspectives (y compris BA et QA) dans les conversations sur ce qu'il fallait construire.<br/>
<br/>
C'est en grande partie grâce à Ward Cunningham, inventeur du wiki et de nombreuses pratiques XP, qui a développé en 2003 un framework de tests appelé [http://fit.c2.com/ FIT] qui permettait aux gens du métier de spécifier des tests dans des tableaux en utilisant des feuilles de calcul. À peu près à la même époque, Brian Marick écrivait des choses concernant le fait d'[http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2 exprimer les tests sous la forme d'exemples].<br/>
<br/>
L'outillage pour supporter le BDD a d'abord évolué chez [https://jbehave.org/ JBehave] avec [http://lunivore.com/ Liz Keogh] comme collaboratrice active et plus tard chez [https://cucumber.io/ Cucumber].<br/>

==Ce que BDD n'est pas==
Le BDD consiste à découvrir ce qu'il faut construire pour aider à enrichir le comportement. BDD n'est pas un framework Agile ou une approche de gestion de projet. Les équipes qui utilisent Scrum ou Kanban avec BDD trouveront quoi mettre dans leurs backlogs et leurs tableaux à des fins de planification. Vous voudrez peut-être même mesurer le nombre de scénarios BDD livrés au lieu de la vélocité, mais ces scénarios sont souvent trop fins pour répondre à des objectifs de planification des versions.<br/>
== Lectures complémentaires ==
Sites Web :
* [https://en.wikipedia.org/wiki/Behavior_Driven_Development Wikipédia]
* [http://behaviour-driven.org/ http://behaviour-driven.org/]
* [http://dannorth.net/introducing-bdd/ http://dannorth.net/introducing-bdd/]
Livres :
* [https://pragprog.com/book/hwcuc/the-cucumber-book "The Cucumber Book:Behaviour-Driven Development for Testers and Developers"] Matt Wynne et Aslak Hellesøy
* [https://manning.com/adzic/ "Specification By Example: How Successful Teams Deliver the Right Software"] par Gojko Adzic
* [https://www.amazon.com/Fit-Developing-Software-Framework-Integrated/dp/0321269349/ "Fit for Developing Software: Framework for Integrated Tests"] par Rick Mugridge et Ward Cunningham
* [https://pragprog.com/book/achbd/the-rspec-book "The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends"] par David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North
Articles :
* [http://www.infoq.com/articles/virtual-panel-bdd Virtual Panel: Specification by Example, Executable Specifications, Scenarios and Feature Injection]
* [http://manage.techwell.com/articles/weekly/three-amigos The Three Amigos: All for One and One for All]
Veuillez ajouter des commentaires pour indiquer d'autres ressources intéressantes sur le sujet. Merci !