Un avis ? Un commentaire ?
Cet espace est pour vous.
Le Behavior Driven Development : vous connaissez « de nom, de loin, vite fait », ça a l’air bien mais il vous manque des précisions. Cet article est votre chance d’y remédier !
Si le BDD fait déjà partie de votre quotidien, vous trouverez peut-être aussi des points de clarification, ou des éléments historiques qui donneront de la profondeur à votre pratique.
D’excellents articles ont été écrits sur le sujet et pour la plupart des questions il vous sera proposé d’en consulter ailleurs sur le web. Cet article est donc une table d’orientation, plutôt qu’un article de fond sur le sujet.
Bonne lecture !
Si vous découvrez tout juste le BDD et souhaitez avoir les notions de base bien en tête, nous vous conseillons avant tout de faire un tour sur cet article, qui pose bien le décor. Vous verrez que, même s’il date de 2012, il n’a pas pris une ride !
Bonne question ; le BDD est-il du ressort des développeurs ou du métier ? Dans la vidéo « Comment échouer un projet en BDD », Vincent Pretre (CucumberStudio, anciennement HipTest) explique comment son entreprise a échoué dans chacune de ces deux approches.
Spoiler : malgré ces deux échecs, l’histoire se termine (très) bien.
Cette question est un véritable marronnier de la blogosphère du test…
Sur la différence entre BDD et ATDD, nous vous invitons à consulter cet excellent article de Marc Hage Chahine sur La Taverne du Testeur. Vous verrez qu’elle est relativement ténue et qu’elle invite au débat.
De manière générale, vous trouverez pas mal d’articles qui se démènent à trouver la différence entre ces deux approches.
Dans leur ouvrage More Agile Testing, Janet Gregory et Lisa Crispin détaillent les deux, tout en indiquant que, de même qu’avec la méthode SBE (Specification By Example), “il s’agit avant tout de commencer par des exemples et des conversations” (p. 148).
La différence entre BDD et TDD est bien plus nette. Le TDD est avant tout une méthode qui concerne les devs, et le test ici est avant tout un test unitaire. Une équipe de développement pourrait très bien se mettre au TDD d’un jour à l’autre, sans que l’équipe de test ne s’en rende compte (ou alors indirectement, en constatant une raréfaction des régressions !).
Le TDD se matérialise par une routine en trois phases :
· La rédaction d’un test unitaire de sorte à ce qu’il soit en échec (il vérifie quelque chose qui n’a pas encore été implémenté)
· La rédaction du code afin que le test unitaire soit au vert
· Le remaniement (ou refacto) du code afin de consolider, entre autres, sa maintenabilité. Et on revient si besoin à l’étape 1 pour préparer une nouvelle vérification !
Rien à voir, donc, avec le BDD et l’ATDD qui mobilisent aussi bien les devs que les QA et le PO. Pour autant, BDD et TDD sont bel et bien liés, car l’inventeur du BDD pratiquait le TDD au quotidien, et a voulu aller plus loin. Pour bien assimiler l’essence du BDD, il est donc intéressant d’avoir en tête le contexte dans lequel cette méthodologie a été fondée.
Ce qui nous amène à la question suivante…
Les bases du BDD ont été posées en 2003 par Dan North, celui qui sera amené à inventer le framework JBehave. A l’époque, la notion de TDD existait déjà depuis 4 ans. Elle portait ses fruits mais des problèmes subsistaient, notamment au niveau de la communication des attendus fonctionnels.
L’histoire de la naissance du BDD est contée dans cet article de Dan North (si vous préférez la version française, c’est ici).
Un premier déclic a eu lieu lorsque Dan North a commencé à utiliser Agiledox, un utilitaire développé par un de ses collègues, qui consistait à transformer des noms de méthodes en langage naturel. Un moyen bien pratique de générer des documents utiles à toute l’équipe.
Puis, de fil en aiguille, il a commencé à modifier les titres de ses tests unitaires en y introduisant le mot « should ». Il a remarqué que cette notion éveillait bien plus de remarques pertinentes (“Ca doit faire ça ? Mais pourquoi ?”) que l’austère notion de test.
Il a ainsi remarqué que la notion de “test” pouvait être trompeuse et ambiguë, alors que la notion de comportement parlait bien plus à l’ensemble de l’équipe. En parlant davantage de comportements que de tests, pas à pas, les blocages qui résistaient au TDD se sont levés. La méthode s’est étendue hors de la sphère du développement pour conquérir aussi l’analyse métier.
Le BDD était né !
Il y a donc un lien fort entre TDD et BDD. Et comme le dit si bien l’article du blog d’Arolla, « De manière un peu caricaturale, le BDD va guider le développement d’une fonctionnalité, tandis que le TDD guidera son implémentation. »
L’histoire du BDD telle que racontée par Dan North est intéressante à plusieurs niveaux.
Premièrement, parce qu’elle retrace précisément toutes les étapes qui ont mené progressivement à l’émergence du BDD. C’est rare d’avoir une genèse qui aille autant dans le détail.
Deuxièmement, parce qu’elle est racontée avec beaucoup d’humilité et qu’on comprend que le BDD a été inventé grâce à une combinaison de contextes, d’outils et de personnes, et non pas du fait d’un éclair de génie de Dan North tout seul dans son bain.
Troisièmement, parce qu’elle illustre la difficile quête de la simplicité. Il est bien facile en 2020 de lire cette histoire en se disant « Finalement, ce n’était que du bon sens ». Le chemin devait être fait une première fois à petits pas avant de former l’autoroute dont on profite aujourd’hui.
Attention, le BDD n’est pas un langage, c’est une méthodologie !
Et la structure « Given / When / Then » (GWT) est simplement un canevas pour formaliser un comportement voulu, pas un langage en tant que tel. Bref, pour parler de manière exacte, il vaut mieux éviter de parler de langage BDD.
La structure GWT semble être ce qu’on retient le plus facilement du BDD, et elle est parfois utilisée comme raccourci pour présenter le BDD à une personne néophyte. Et donc, par abus de langage, on peut donc parfois entendre « un test en langage BDD ».
Comme l’explique très bien Vincent Pretre dans la vidéo évoquée précédemment « Comment échouer un projet en BDD », ce n’est pas parce qu’on utilise le formalisme GWT qu’on fait du BDD, et inversement certaines équipes travaillant en BDD n’utilisent pas ce formalisme. Il fait un parallèle très parlant avec l’utilisation des post-its, qui n’est en aucun cas un gage d’agilité, même si cet artefact est largement représenté dans les images d’Épinal de l’agilité.
Les outils de BDD constituent un « passe-plat » efficace entre script et langage naturel. Mais… dans quel sens ? Dans un billet de blog de la décennie précédente (mais qui n’a pas non plus pris une ride), Jonas Bandi différencie deux types d’outils de BDD :
· Ceux dont l’output est en langage naturel (là, l’équipe de développement est un peu le centre de gravité de la démarche BDD)
· Ceux dont l’input est en langage naturel (là, toutes les personnes liées au projet peuvent être impliquées de la même façon)
La façon dont on souhaite travailler va donc avoir un impact majeur sur l’outil ou la chaîne d’outils choisie.
Le framework JBehave, initié par Dan North, permet d’utiliser les termes Given, When et Then en tant qu’annotations Java. Ce sont les rapports de test qui sont en langage naturel. Cet outil appartient donc à la 1ère catégorie. Le principe est similaire dans le framework Spock (oui, comme le Spock de Star Trek !)
Gherkin, intégré au framework Cucumber, est une syntaxe utilisant la structure GWT, avec une panoplie d’autres mots-clés. Les comportements sont exprimés en langage naturel, avec des fonctionnalités comme des tableaux de jeux de données. On est là dans la 2ème catégorie.
Cette typologie montre bien à quel point le formalisme GWT ne suffit pas à déployer une démarche BDD. Si on vise une collaboration inter-équipes (la philosophie même du BDD), on va avoir tendance à préférer un outil de la deuxième catégorie.
On pourrait même en arriver à penser que certains outils dits de BDD pourraient présenter un risque de nous éloigner des principes du BDD. A méditer…
Libre à vous de développer l’usage de l’expression « Programmation pilotée par le comportement », même si elle n’est pas très usitée !
Pour info, le syllabus ISTQB niveau Fondation – Agile Tester s’éloigne un petit peu de la traduction littérale et parle de « Programmation pilotée par les tests de comportement ».
La question se pose effectivement, mais sachez que la transition vers le BDD n’est pas évidente non plus sur un nouveau projet. Des aspects relevant de la culture d’entreprise et des interactions personnelles sont en jeu, ce n’est pas seulement une histoire d’outils ou de process.
Pour ce qui est des projets existants, cela ne coule a fortiori pas de source, mais ce n’est pas impossible. Dans le prochain article, notre invité Florent Vaution vous parlera de son expérience chez Ouest-France, où il a mis en place une méthodologie BDD dans un contexte legacy. Préparez-vous, ça va être passionnant !
Cet espace est pour vous.