Temps de lecture estimé : 31 minutes
BDD ou Behavior-Driven Development : Comment intégrer la Programmation Pilotée par le Comportement dans notre code ?
Le Behavior-Driven Development (ou BDD) est une méthode de développement pilotée par le comportement qui vise à s’assurer que les besoins métiers ont bien été respectés.
C’est une technique de programmation avancée que l’on retrouve souvent chez les adeptes du DDD ou des tests.
Tirée de la méthodologie agile, elle encourage la collaboration entre les différents membres de l’équipe, du développeur à l’expert métier en passant par le product owner ou le chef de projet.
L’approche BDD se base sur des exemples issus de cas d’usages précis.
En tant que… Si je… Il se passe…
“As a…, I …, So that…”
Les scénarios (ou exemples) que l’on en tirera permettront d’avoir une compréhension commune et précise de ce qui est à faire.
On s’assure ainsi que la fonctionnalité demandée couvre tous les cas d’usages métiers pour éviter les problèmes futurs en production.
Comme le Domain-Driven Design (ou DDD), le Behavior-Driven Development (ou BDD) vise à retranscrire au mieux le besoin business dans notre code.
C’est quoi le Behavior-Driven Development ?
Le BDD permet d'exprimer les problématiques métiers aux travers d'exemples pour s'assurer que tous les membres de l'équipe ont bien compris le besoin et avancent dans la même direction.
Tout le monde discute ensemble, et c’est ainsi que l’on arrive à expliciter clairement ce qui est attendu.
Les cas de tests (que l’on fera par la suite) couvriront ainsi TOUS LES BESOINS d’une fonctionnalité donnée.
J’avais fait un thread sur Twitter pour raconter ma première expérience d’il y a quelques mois. 👇
Très souvent quand on aborde le Behavior-Driven Development, on parle de
Et on va voir tout ça dans l’article.
Le behaviour driven development est avant tout un processus de forte collaboration entre les équipes.
Qui n’a jamais développé une feature pour rien ?
Que ce soit parce que les besoins avaient changé ou une incompréhension avec le client ?
Le Behavior-Driven Development permet d’éviter les incompréhensions entre :
La traduction du besoin client en règles de gestion est toujours compliquée, des informations se perdent souvent malgré un bon workflow.
Comme la communication est la clef, BDD s’assure que tout le monde a bien compris les tenants et les aboutissants d’une feature.
Les développeurs restent ainsi concentrés sur les besoins business tout au long de la phase de développement.
C’est de cet article de Dan North que serait partie la genèse du projet au début des années 2000.
BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology.
Dan North
Le Behavior-Driven Development est donc une méthodologie qui vise à redonner du sens aux développements demandés par les équipes métiers.
Note à moi-même 👇
Je suis toujours étonné de découvrir que des concepts qui ont 20 ans + comme : TDD, DDD, BDD, SOLID, la méthodologie agile, l'eXtrem Programming etc, sont, encore aujourd'hui, des bonnes pratiques.
On n’aurait rien inventé de mieux depuis ?
Pour en revenir à l’histoire du Behavior-Driven Development, on ne sait pas grand-chose si ce n’est que Liz Keogh est venue rapidement derrière pour décrire le sujet.
Les exemples et les conversations que l’on a avec le business permettent de créer des exemples concrets de l’implémentation que l’on souhaite.
Les exemples décrivent le comportement applicatif et sont essentiels à la compréhension d’une demande.
Ils suppriment les ambiguïtés, permettent d’être plus clairs, plus précis de challenger le système pour vérifier qu’il est cohérent.
BDD is the art of using examples in conversations to illustrate behaviour.
Liz Keogh
C’est ça le Behavior Driven Development.
En plus de la règle métier (notre critère d’acceptation), on illustre le besoin avec des conversations fournies d’exemples.
En y repensant, dès qu’on ne comprend pas une règle de gestion on demande souvent des exemples à notre client.
Alors pourquoi ne pas prendre de suite une longueur d’avance ?
Le BDD est un acronyme pour « Behaviour-Driven Development » ou pour « Behavior-Driven Development ».
Les deux fonctionnent.
En anglais, « Behavior » et « Behaviour » signifient la même chose.
https://ell.stackexchange.com/questions/202548/what-is-the-difference-between-behavior-and-behaviour
« Behaviour » est épelé ainsi chez les Britanniques, alors que « behavior » est employé par les Américains, et semblerait-il, le reste du monde.
Le cycle de BDD se décompose en 3 étapes que l’on verra juste après dans des sections dédiées :
Tout d’abord, on recueille les besoins (la découverte).
Ensuite, on va aller reformuler le besoin métier sous forme de cas d’usages, puis d’exemples (la formulation).
Enfin, on testera la bonne mise en application des règles métiers directement dans notre code (l’automatisation).
C’est une discussion entre tous les membres de l’équipe aussi appelée « Specification Workshop » pour « Atelier de spécification ».
La méthode des « 3 amigos » est une manière d’organiser les équipes afin de converser avec tout le monde.
On ne met personne de côté.
Le BDD a un intérêt pour les business analysts, les product owners, les testeurs, les développeurs, les experts métiers…
Tout le monde finalement.
Les 3 amis sont des personnes qui ont les rôles suivants :
En théorie à la fin de la réunion des 3 amis, tous les partis prenants doivent avoir atteint leur but.
Note : Les 3 amigos peuvent devenir 3 amigos + (si une personne supplémentaire est nécessaire au bon déroulement de la séance, comme un UX Designer, un Admin Sys ou une autre personne).
Une fois que tout le monde s’est bien assuré que tout le monde se soit bien compris aux travers des exemples, on peut :
D’ailleurs grâce au BDD, comme on a des exemples précis de ce qui est attendu, c’est beaucoup plus facile pour le développeur de tester son code.
Le cahier de recette pour tester les différentes fonctionnalités est donc grandement réduit !
On gagne du temps de tests manuels…
En BDD, il faut avoir au centre du terrain les parties prenantes.
Souviens-toi du premier principe de la méthodologie agile :
Pour résumer, ce qu’est le Behavior Driven Design, on peut s’appuyer sur les actions suivantes :
Voici comme cela se caractérise en un diagramme :
Quand on aborde le Behavior-Driven Development vs Test-Driven Development, on entend parfois que le BDD, c’est le TDD bien fait.
Personnellement je pense que les 2 sont complémentaires.
TDD est centré sur le fait de vouloir livrer un code qui corresponde au besoin énoncé via les tests :
TDD is building the thing right.
BDD est centré sur le fait de vouloir livrer un code qui correspond au besoin énoncé via des exemples :
BDD is building the right thing.
La différence est subtile mais elle a du sens.
Il semblerait que le BDD soit issu de la volonté de combler le manque d’implication métier et de compréhension business dans TDD.
Ce qui se comprend totalement car TDD ne s’occupe (essentiellement) pas de savoir si ton code répond à la problématique métier, mais s’il fonctionne correctement.
TDD se concentre sur la création de fonctionnalités pilotées par les tests afin de s’assurer que le code exécuté fait bien ce qu’on lui demande.
BDD est une méthode qui permet d’amener le besoin sous forme d’exemples via des scénarios métiers, avec OU sans tests.
BDD met l’accent sur le comportement, TDD sur les tests.
Oui, et c’est souvent encouragé. Le BDD et le TDD ne sont pas incompatibles et peuvent être utilisés conjointement pour apporter davantage de stabilité au projet.
Le canevas « Given, When Then » décrit un scenario, « As, I, So that » décrit un critère d’acceptation.
On retrouve parfois l’acronyme BDD pour Behaviour-Driven Design.
Un peu comme dans « Domain-Driven Design ».
Rien d’étonnant quand on sait que les deux méthodes visent à designer un logiciel qui réponde aux besoins du métier.
Pour autant la bonne formulation est bel et bien « Behaviour-Driven Development », « Behaviour-Driven Design » semble être une erreur d’interprétation.
Behavior Driven Design également du coup.
BDD est une approche qui vise à s’assurer que tout le monde se soit bien compris.
Les user-stories dans Jira / Redmine, ou n'importe quel autre outil de ticketing ne suffisent généralement pas à ce que tout le monde se comprenne.
Des tickets très bien faits ne justifient pas l’absence de communication.
Comme le Behaviour-Driven Development réuni autour de la table toutes les parties prenantes, on s’assure que le même besoin soit bien compris par tout le monde.
Est-ce que cette fonctionnalité peut être améliorée avec des exemples ?
Sûrement.
Qui n’a jamais développé quelque chose qui s’est vu être incompris par le client au moment de la livraison ?
Pas moi en tout cas.
BDD souhaite éviter cela.
Les fonctionnalités dans un système doivent servir de documentation.
Car dès que l’on commence à écrire de la documentation à côté (comme dans les tickets) elle devient obsolète.
Le code est toujours up-to-date, la documentation, quasiment jamais.
C’est pour cela que Gherkin permet d’illustrer aussi bien les tests dans l’application, les tests sont toujours à jours.
On lie la documentation avec le code pour qu'il n'y ait aucun décalage entre les deux.
Par exemple, pour reprendre un gros projet chez Beelance, on a fait le choix de décrire toutes les parties fonctionnelles en amont pour les relier au code dont on était peu sûr du résultat attendu.
Ceci nous a permis de transmettre des exemples détaillés à la future équipe…
Afin qu’elle comprenne mieux le comportement de l’application.
Le Behavior Driven Development permet de faire des tests automatisés oui, mais BDD n’est pas un framework de test.
Ces tests d’acceptation sont très utiles une fois automatisés car ils permettent d’avoir une « documentation vivante » comme on vient de le voir.
Mais les tests automatisés ne sont qu’une partie de ce que propose le framework BDD.
Or, les tests fonctionnels sont souvent utilisés comme exemple pour décrire BDD.
Ce n’est qu’1 (des 3) partie de l’outil.
Avoir Gherkin dans son projet ne veut pas dire que tu fais du BDD.
Au mieux cela signifie que tu l’utilises comme outil de tests.
Sans plus.
Ce serait comme dire que faire de tests c'est comme faire du TDD.
Le behavior driven development est avant tout une méthodologie, pas un pattern technique.
Si tu commences à écrire tes user stories / use-cases, puis tes exemples pour créer des tests…
Tu risques de ne pas refléter le comportement de l’utilisateur…
Et de rajouter de la complexité technique là où il n’y en a pas.
Pour rappel, le but du BDD c’est : écrire du code qui a de la valeur pour le business.
Les tests ne sont qu’un effet de bord et permettent de relier les use-cases métiers au code afin de faire une pierre deux coups.
Quand on écrit ses features, il faut se demander :
Et si je souhaite utiliser cette feature en CLI ? Ou via mobile, http ? Ou si elle est lancée par un event externe ? Puis-je tester mon scenario ? Si non, alors il y a des chances que je me concentre sur l'implémentation et pas sur le besoin.
On verra plus tard comment éviter ça.
BDD est une pratique collaborative.
Le Behavior-Driven Development permet de créer une connaissance commune et partagée des besoins métiers à travers la collaboration.
Le but est de travailler ensemble, et non de se passer des documents ou des besoins à travers des tickets…
Tu vois ce que je veux dire ? 😅
La phase de discovery, c’est la présentation de ce qui est attendu, aux équipes.
Y compris…
Et surtout…
Aux développeurs.
On comunique sur les besoins pendant qu’on juge des priorités associées.
Pour donner un exemple 👇
Auparavant dans nos anciennes réunions, chacun avait son template pour décrire les tests associés et ça nous prenait beaucoup de temps et d’énergie.
On faisait un « cahier de tests » sur mesure au business pour qu’il puisse tester nos features de bout en bout.
Mais comme chacun avait sa manière de faire, l’efficacité était TRÈS variable…
Dans la méthodologie agile, on retrouve souvent des US aussi appelées « User-Stories ».
Elles servent à décrire le besoin avec un format défini.
Ce format nous permet d’avoir un cadre, de manière à ce qu’on sache de quoi on parle.
Que tout le monde, sache de quoi on parle.
As a <role> I can <capability>, so that <receive benefit>.
Exemple d’user-story.
Ces histoires utilisateurs servent à énoncer un besoin business.
Une fois compris par les développeurs, on pourrait créer nos cas de tests post-développement (sans forcément utiliser BDD).
Voici un template qui décrit une fonctionnalité attendue.
Cela fait une très bonne base pour écrire de belles user-stories / critères d’acceptation (utilisés avec la méthode BDD ou non).
Title (feature):
An explicit title.
Acceptance criteria:
A short introductory section with the following structure:
As a:
the person or role who will benefit from the feature;
I want:
the feature;
So that:
the benefit or value of the feature.Bien entendu ce template est une inspiration, il en existe d’autres.
Mais commençons par rédiger nos fonctionnalités avec ce format…
On vient de récupérer le besoin métier avec une US, top.
Il nous faut maintenant recueillir des exemples clairs du comportement attendu (en utilisant des terminologies business) puis les challenger.
Autrement dit « Gérer les user-stories en fonction de ce que l’on a compris du métier ».
Pour les équipes, il s’agit de formuler ou de reformuler les besoins du métier en exemples concrets de ce que l’on souhaite implémenter.
BDD est en grande partie connu pour ses tests et notamment ses tests grâce au Domain-Specific Language.
Le langage spécifique à un domaine fonctionnel est un langage commun entre l’équipe technique et l’équipe business.
ON VA ENFIN POUVOIR SE PARLER !
Tout le monde parle la même langue, comme avec l’Ubiquitous Language du DDD !
Car non, les personnes qui ne sont pas développeurs ne comprennent pas le code…
DSL (et Gherkin du coup) va permettre de créer des phrases simples pour exprimer une opinion forte et valider un besoin.
Ces acceptations sont souvent automatisées à l’aide de scripts pour faire du testing.
MAIS CE N’EST PAS TOUJOURS LE CAS.
On peut écrire les scénarios Gherkin pour définir le besoin et les exemples sans pour autant y relier de tests (mais c’est moins efficace on est d’accord).
Gherkin est une syntaxe qui est implémentée dans de nombreuses librairies :
Cette syntaxe permet d’exprimer un besoin dans un langage humain !
Quoi de mieux pour que le business comprenne les devs et inversement ?
Le Behavior-Driven Development donne un cadre pour écrire des spécifications métiers.
En changeant légèrement l’exemple ci-dessus, voici ce que ça donne avec quelques scenarios :
Afin de gagner du temps, on peut être tenté d’utiliser un Scenario Outline (un tableau) afin de rentrer les valeurs attendues.
En français, on peut employer le terme « Scenario tabulaire ».
Ces tables peuvent être aussi grandes qu’on le souhaite (on verra des exemples concrets plus bas).
La seule règle à absolument respecter :
Si tu as suivi ce qu’est le Behavior-Driven Development, tu sais que le business doit valider ces fichiers avec les développeurs pendant ou après leur écriture.
Mais voici d’autres règles pour t’aider à structurer de bonnes spécifications fonctionnelles.
should » dans le comportement pour clarifier la volonté de la fonctionnalitéensure » pour différencier les résultats des effets secondaires induits par la fonctionnalitéCe qui est dur, c’est de comprendre l’autre être humain en face.
Que ce soit dans le cadre d’un développement ou…
Dans la vie. 👩❤️👨
Heureusement pour ce qui est du dev, on a des outils.
Le canevas « Given, When, Then » vient donner du contexte et du détail à un besoin grâce aux exemples.
L’état général du système, le contexte sur lequel on se trouve.
Ce qu’on essaye de faire, le comportement de l’utilisateur.
(Elle est généralement là, la valeur de la feature.)
Changement de l’état, c’est le résultat que l’on souhaite en fonction de la valeur que l’on ajoute.
Permet de lier des phrases entre elles que ce soit avec Given, When ou Then.
Voici le template d’une user-story (que l’on a vu tout à l’heure), avec un seul scenario (pour commencer).
# La demande du business
# -------------------------------
Title (feature):
An explicit title.
Acceptance criteria:
A short introductory section with the following structure:
As a:
the person or role who will benefit from the feature;
I want:
the feature;
So that:
the benefit or value of the feature.
# Les résultats attendus
# -------------------------------
Scenario:
A description of each specific scenario of the narrative with the following structure:
Given:
the initial context at the beginning of the scenario, in one or more clauses;
When:
the event that triggers the scenario;
And:
...
Then:
the expected outcome, in one or more clauses.
And:
...
Scenario Outline: title
Given .... <placeholder 1> .....
When .... <placeholder 2> ...
Then ... <placeholder 3> ...
Examples:
| placeholder 1 | placeholder 2 | placeholder 3 |
| value | value | value |
| value | value | value |Un test d’acceptation permet de définir un besoin métier.
Fonctionnalité : Les produits vendus peuvent être remboursés au prix qu’ils ont été vendus.
Exemple d’une fonctionnalité (test d’acceptation).
En BDD, les scénarios représentent des exemples, des comportements attendus dans la fonctionnalité.
Scénario : Remboursement d’un produit vendu en plein tarif.
Scénario : Remboursement d’un produit vendu avec une remise.
Scénario : Remboursement d’un produit vendu avec une carte cadeau.
…
Exemple de scénarios.
Pour chaque exemple via un scénario, une règle de gestion va s’appliquer.
Encore une fois c’est le plus dur…
Que tout le monde se comprenne.
Heureusement le Behaviour-Driven Development a des outils pour nous permettre de rédiger ces .features, ensemble.
En BDD, la conversation est très importante dans la définition des exemples.
Le comportement de l’application toute entière est reflété à travers ces conversations, en s’aidant notamment des scénarios.
Le Behaviour-Driven Development, c’est avant tout de la conversation entre tous les membres de l’équipe.
Car si on ne discute pas avec le métier pour trouver les exemples les plus farfelus, on ne risque pas de couvrir tous les potentiels problèmes qui peuvent arriver.
Cela permettra notamment
Le mode interview des personnes du métier fonctionne aussi très bien pour capter le besoin.
Challenger le contexte (le Given) permet de couvrir un maximum de cas d’usages et de s’assurer que tout est couvert par la feature.
“Is there any other context which, when this event happens, will produce a different outcome?”
« Est-ce qu’il existe un autre contexte qui, quand cet évènement arrive, produit un résultat différent ? »
https://lizkeogh.com/2011/09/22/conversational-patterns-in-bdd/
Aussi, les développeurs doivent challenger un maximum le métier.
Challenger et comprendre le contexte (le Given) en se posant la question :
Ah ouais ? Et si je fais ça, il se passe quoi ?
Un développeur challengeant 😈
De la même manière que l’on challenge le contexte, on peut également challenger le résultat (le Then).
“Given this context, when this event happens, is there another outcome that’s important? Something we missed, perhaps?”
Sachant le contexte, quand cet évènement se produit, est-ce qu’un autre résultat serait important ? A-t-on manqué quelque chose ?
https://lizkeogh.com/2011/09/22/conversational-patterns-in-bdd/
Si jamais le besoin client a besoin d’être visuellement représenté…
L’example mapping est une solution qui modélise une User Story à la sauce BDD.
On a quelque chose de visuel qui représente notre scénario.
On peut ainsi travailler en équipe avec le métier en mode collaboratif !
Le BDD, c’est génial pour recueillir un besoin business clair pour tout le monde.
MAIS…
Mieux encore.
La documentation peut être automatisée (on parle de living documentation).
Elle reflète les besoins dans le code en temps réels et s’assure que le code reflète bien les besoins business.
Maintenant que l’on a le besoin et des exemples pour être sur et certain de bien avoir tout compris…
On va pouvoir coder !
On appelle aussi cette phase « acceptance-test driven design ».
Car on va scripter les tests d’acceptations.
Personnellement, j'adore le fait de pouvoir coupler ma documentation fonctionnelle avec mon code ! 😍
Les tests (le plus souvent unitaires chez moi) faits avec Gherkin m’apportent tellement de sérénité sur mes développements…
Ce sont les scénarios vus avec le métier qui vont directement tester mon code.
Quoi de mieux pour avoir une recette en béton ?!
Il faut que le code que tu produis respecte les besoins fonctionnels définis plus haut avec le métier.
Pour cela, rien de mieux que des tests unitaires bien faits reliés à notre scenario.
Attention, je n’exclue pas les tests fonctionnels (les e2e) pour tester mes fonctionnalités.
Je le fais même relativement souvent sur des APIs que je ne maîtrise pas afin d’avoir une compréhension rapide de ce qui est attendu.
Pour autant, 90% de mes tests sont des tests unitaires car ils me permettent de tester le cœur de mon application, les règles métiers que je code.
Les 10% restant servent à vérifier via les e2E que les principaux scénarios utilisateurs sur le site sont bien fonctionnels.
Les steps definitions permettent de relier des use-cases métiers depuis Gherkin aux tests dans le code.
C’est un sacré plus que permet le framework Behavior Driven Development.
On peut grâce à cela tester une feature sous différentes configurations, différents profils.
Comme les implémentations changent plus rapidement que les règles métiers, on veillera surtout à tester ces dernières.
Ces fichiers se trouvent généralement dans un dossier features/.
Personnellement, je mets les critères d’acceptations dans des groupes (ici authentication).
C’est plus facile d’avoir une seule fonctionnalité par fichier (ce que l’on teste).
Tous mes scénarios (mes exemples), comme :
Se retrouvent dans ce même fichier (par exemple login).
Voici ce que ça donne. 👇
features/
├── environment.py
├── step_definitions
├── authentication
│ ├── login.py
│ ├── forget-password.py
│ ├── register.py
│ └── magic-link.py
└── stories
├── authentication
│ ├── login.feature
│ ├── forget-password.feature
│ ├── register.feature
│ └── magic-link.feature
Comme tu peux faire du BDD sans faire de tests.
Tu peux tout aussi faire du BDD avec des tests, mais sans Gherkin, simplement avec un framework de test « classique ».
Dan North propose de respecter les normes suivantes pour réaliser ses tests :
Behaviour ;should ; camelCase.Et je trouve que c’est exactement vers cela que l’on doit se diriger.
Je disais un peu plus haut qu’avec le Behavior-Driven Development, j’aimais concentrer mes tests sur la partie unitaire.
C’est vrai.
Pour autant, j’utilise les tests fonctionnels automatisés aussi (les tests bout à bout ou end-to-end (e2e)).
Pour te donner le contexte, on a dû faire la documentation technique d’une app de chez nous et donner des exemples d’utilisations à l’autre agence qui nous a rejoint sur le projet.
Comme on n’était pas certain de comment marchait l’API (il y avait un gros volume de données)…
On s’est dit qu’utiliser Gherkin avec le BDD en couplant des tests fonctionnels automatisés serait pas mal.
On avait une grosse refactorisation à faire et on voulait aussi s’assurer de ne rien défoncer.
Voici ce que nos tests e2e ont donné avec Gherkin et Behave (en Python).
Et la partie qui s’occupe d’attaquer l’API.
Quand notre lead developer a quitté l’équipe, j’ai pris la décision de revoir notre flow de développement afin que l’on continue d’être efficace.
On a donc listé les problèmes des équipes et on a décidé d’agir en fonction.
Sans rentrer dans les détails, voici notre nouveau flow de développement (qui inclut du Behavior-Driven Development).
Si jamais tu regardes de prêt, tu verras que le flow BDD n’est pas exactement respecté.
Un flow, ça se modifie, il faut que ça mette tous les acteurs en accord avec ce qui est attendu.
Et compris dans les process…
On a donc évité d’être trop rigide. 😊
Le mieux pour proposer BDD, c’est de commencer à l’implémenter seul, de son côté.
Puis de démontrer des résultats obtenus…
Bien sûr, le développement piloté par le comportement n’est pas infaillible.
Et si, comme moi, tu as été hypé par tous ses bénéfices.
Il faut que tout le monde partage la même vision des bénéfices du BDD.
Car cela demande un investissement au lancement, dans les réunions, la rédaction des feature files, la communication, le processus…
Voici ce qui peut casser BDD et comment ne pas tomber dans ces dérives.
On se fiche de l’apparence du produit.
Ici, on ne se sert pas nécessairement de BDD pour faire des tests fonctionnels.
On se sert de BDD pour fournir des exemples métiers.
Donc peu importe que le bouton sur lequel on clique s’appelle « rechercher », ou « search ».
Ce qui compte c’est tout le comportement derrière.
Un scénario d'une règle de gestion ne doit pas dépendre du texte d'un bouton ou d'une URL.
Il ne faut pas décrire les implémentations (l’UI) et compter dessus dans les features.
L’amalgame est souvent fait en réduisant BDD à des tests fonctionnels.
Encore une fois, il s’agit surtout de trouver des exemples concrets à des besoins métiers afin de les comprendre.
Avec des tests fonctionnels, ou non !
Si les scenarios et les fichiers sont trop longs (ce qu’ils sont déjà avec BDD), il ne faut pas hésiter à les découper.
L’organisation est la clef pour avoir un flow BDD sur le long-terme !
Given ...
And ...
And ...
And ...
And ...
When...
And ...
And ...
And ...
And ...
Then...
And ...
And ...
And ...
And ...Ne pas hésiter à splitter les scénarios pour avoir des sorties plus fines.
2 sorties attendues pour un scénario c’est déjà pas mal.
BDD, c’est avant tout le comportement attendu et on se sert d’exemples pour cela.
Voici un exemple de scénario qui peut largement être amélioré.
Scénario : pouvoir acheter de l'alcool dans un magasin
Etant donné qu'une personne trop jeune ne peut pas acheter d'alcool
Quand j'essaye d'acheter une bière
Alors je suis informé que je n'ai pas l'âge requisLa règle de gestion semble simple…
Mais l’exemple fourni ne comporte rien qui puisse être utilisé pour tester cette règle.
Un bon scénario doit au moins répondre à une problématique…
AVEC DES DONNÉES CLAIRES.
Scénario : pouvoir acheter de l'alcool dans un magasin
Etant donné qu'une personne trop jeune ne peut pas acheter d'alcool avant "18 ans" en "France"
Et que je suis actuellement un français âgé de "17 ans"
Quand j'essaye d'acheter "une bière"
Alors je suis informé que je n'ai pas l'âge requis pour acheter "une bière"Notre scénario répond ici à un exemple précis pour un comportement donné !
Là c’est clair. 👌
Apprendre le BDD ça ne s’improvise pas.
Il faut pratiquer…
Car écrire ses premières features en mode Gherkin ça demande un petit moment d’adaptation.
Mais le Behaviour-Driven Development c’est tellement fascinant que j’ai pris du plaisir à consulter les contenus ci-dessous. 👇
Ils donnent une bonne approche du BDD.
Ce livre offre une bonne introduction à BDD avec le TDD.
Je n’ai malheureusement pas pu le finir avec mon tour du monde mais j’ai hâte de le reprendre en revenant.
En plus, le livre a été écrit par des français. 🇫🇷
J’ai trouvé cette conférence ultra-stylée, elle m’a donné envie de pratiquer BDD encore plus que maintenant.
Pour apprendre la base de BDD et ses principaux principes.
On se concentre trop sur la technique et pas assez sur la retranscription du besoin.
Une masterclass sur BDD, DDD, TDD…
Franchement, à regarder.
J’aime beaucoup le contenu de Liz qui te permet de te challenger sur des concepts de BDD plus avancés.
Ici on est challengé sur ce qu’on sait du Behavior-Driven Development et ce qu’on en a compris.
Comme avec Dan North, c’est du contenu « à la source », donc à consulter sans modération. 😊
En ayant longuement travaillé sur le Domain-Driven Design, j’ai naturellement découvert le Behavior-Driven Design.
Je ne peux pas te dire à quel point j’ai été séduit.
On parle d’une méthode qui permet de transcrire littéralement, les besoins métiers dans le code.
Quoi de plus efficace pour s'assurer que notre code en production correspond bien à ce qui a été demandé ?
Ça m’a beaucoup plu !
Formé aux tests depuis mon passage en freelance, j’ai adoré décrire mes features avec Gherkin pour pouvoir mapper les exemples métiers aux tests unitaires.
Durant les prochaines semaines je vais continuer de me former avec mon équipe à la gestion des features à la sauce BDD.
De la découverte à l’automatisation en passant par la formulation.
Je suis persuadé que ça nous apportera encore plus de stabilité et de qualité dans nos projets.
Et toi, ça te dit d’implémenter BDD ?
Pour lire plus de contenu similaire dans le même thématique.
Tres pertinant
ça fait grave plaisir à lire, merci !
Hello,
Je dirais plus que très pertinent
– super exhaustif sur les problématiques du métier et les écueils potentiels
– super pédagogue et très bien écrit
– s’adresse à tous les niveaux et à la portée de tous grâce à une super présentation
Je me suis permis de te citer dans une doc en interne où nous implémentons du BDD en contexte agile. Je voulais t’adresser mes compliments pour ce travail de qualité.
Hello Olivier,
Juste merci à toi d’avoir laissé ce commentaire, ça m’a fait super plaisir à lire, vraiment, merci <3