Voir la source de BDD est équivalent à TDD si...

[[Category: Portail Product Owner]]
[[Category: Portail Equipe de développement]]
[[Category: Tests]]
[[Category: BDD]]
Auteur : Dan North<br/>
Source : [https://dannorth.net/2012/05/31/bdd-is-like-tdd-if/ BDD IS LIKE TDD IF…]<br/>
Date : 31/05/2012<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 04/04/2019<br/>
----
Traduction :<br/>
<br/>
J'ai remarqué qu'un certain nombre de personnes ont récemment déclaré que le BDD n'est en fait que du TDD, tel que [https://twitter.com/unclebobmartin/status/207281653582802944 Robert Martin sur Twitter] et [https://groups.yahoo.com/neo/groups/extremeprogramming/conversations/topics/157759 Ron Jeffries sur la liste XP]. Je peux comprendre d'où provient cette manière de penser et j'aimerais offrir mon point de vue.<br/>
<br/>
Est-ce que le BDD est la même chose que le TDD ? Oui, si vous êtes développeur et que toute votre équipe est composée de développeurs, et que toutes les parties prenantes sont des développeurs et que le seul spécialiste du sujet fait partie de l'équipe. Ce qui était le cas pour l'équipe Chrysler C3 et les toutes premières équipes XP. (jetez un coup d'oeil à l'équipe originale de C3 : 10 développeurs de classe mondiale et un spécialiste du sujet)<br/>
<br/>
BDD, c'est la même chose mais pour un public plus large : testeurs, analystes, chefs de projets et de programmes, plusieurs spécialistes couvrant de multiples domaines métier interdépendants. Il est intéressant de noter que la population prônant BDD == TDD est entièrement composée de développeurs et voient nécessairement le monde à travers la paire de lunettes des développeurs : Bob Martin, Ron Jeffries et d'autres disent que l'énoncé "BDD, c'est juste du TDD" est vrai dès que l'approximation de "toutes les personnes qui livrent quelque chose sont des développeurs". Dès que cette condition préalable échoue, le BDD devient une chose différente et plus large : cela devient un mode de communication entre toutes ces parties prenantes pour créer une vision cohérente et unique et pour livrer des choses en fonction. C'est toute la valeur associée à [https://gojko.net/books/specification-by-example/?src=/ la documentation vivante] et cela montre pourquoi vous n'en avez pas besoin jusqu'à ce que vous le fassiez : si vous faites partie de cette petite équipe uniquement composée de développeurs, vous serez nickel avec TDD.<br/>
<br/>
On peut soutenir qu'une équipe ne devrait pas être composée d'autre chose que de développeurs, dans les rôles polyglottes du testeur, de l'analyste, ..., auquel cas BDD et TDD se confondent à nouveau dans le même espace. Mais dans le type d'organisations et d'équipes qui ont donné naissance et façonné le BDD, nous devons résoudre des problèmes de communication plus complexes qui dépassent (par définition) le cadre du TDD.<br/>
<br/>
J'ai été entièrement intégré dans de petites équipes de développeurs au cours des deux dernières années et c'est pourquoi je m'étais un peu éloignée de la communauté BDD. Des gens comme Liz Keogh, Gojko Adzic et Chris Matts furent là pour apporter des choses comme les options réelles et les [https://en.wikipedia.org/wiki/Specification_by_example spécifications par l'exemple], et des gens comme Aslak Hellesøy et Matt Wynne ont trouvé comment gérer un grand nombre de tests sur le long terme et à grande échelle. Liz a récemment écrit un article sur la façon dont [https://lizkeogh.com/2012/05/30/showcasing-the-language-of-bdd/ changer de langage aide à clarifier l'intention].<br/>
<br/>
Kent Beck décrit XP comme une tentative de mettre les gens du métier et de la technique sur la même longueur d'onde, et j'ai le même objectif pour BDD. N'oubliez pas que TDD constitue une petite partie de XP. Le BDD est devenu plus large que s/tester/devoir/, parce qu'il essaie de résoudre un problème plus large.