BDD : Behavior-Driven Development

BDD ou Behavior-Driven Development : Comment intégrer la Programmation Pilotée par le Comportement dans notre code ?

Laisser un commentaire

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.

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.

  1. Behavior-Driven Development : Definition
    1. Le vrai pouvoir du BDD
    2. BDD pour Behavior-Driven Development
    3. BDD pour programmation pilotée par le comportement
    4. Behaviour-Driven Development ou Behavior-Driven Development
    5. BDD, comment ça marche ?
    6. Principes et pratiques du Behavior-Driven Development
    7. BDD vs TDD
    8. Behaviour-Driven Design
  2. Pourquoi faire du Behavior Driven Development ?
    1. Living Documentation
    2. BDD pour les tests unitaires et fonctionnels
    3. Avantages de BDD ✅
    4. Inconvénients de BDD ❌
  3. Behaviour-Driven Development (1) : Discovery
    1. Faire connaître le besoin
    2. Tests d'acceptances / acceptations et user-stories
    3. Template d'une user-story
  4. Behaviour-Driven Development (2) : Formulation
    1. Gherkin : Le Domain-Specific Language (DSL)
    2. Exemples de DSL en Anglais et en Français
    3. Règles pour de bonnes features
    4. Scenario : given, when, then
    5. Template d'une user-story avec scenarios
    6. Outils pour communiquer avec les équipes
  5. Behaviour-Driven Development (3) : Automatisation
    1. Acceptance-test driven design
    2. Scenario
    3. Step definitions
    4. Organisation des .features
    5. Tests BDD sans Gherkin ?
    6. Tests e2e
  6. Comment faire du Behavior-Driven Development dans ses projets ?
    1. Comment échouer avec BDD ?
  7. Apprendre le Behavior-Driven Development
    1. Livre : Open-Source sur le Behavior-Driven Development
    2. Livre : Software craft: TDD, Clean Code et autres pratiques essentielles
    3. Vidéo : Matt Brunt - Behaviour Driven Development and Behat: Telling Stories Through Code
    4. Vidéo : Cucumber - Discovery: The first practice of Behaviour-Driven Development
    5. Vidéo : WealCome - BDD, DDD, ATDD et TDD expliqués !
    6. Présentation de Liz Keogh sur le “Behavior Driven Develoment"
  8. Conclusion

#Behavior-Driven Development : Definition

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. 👇

Behavior-Driven Development tweet pour apprendre
https://twitter.com/alexsoyes/status/1509079257535893508

Très souvent quand on aborde le Behavior-Driven Development, on parle de

  • Use-cases,
  • User Stories,
  • Scenarios,
  • Scenario Outlines,
  • Acceptance criterias,
  • Critères d’acceptation,
  • Gherkin,
  • Features,
  • Steps,
  • Step definitions,
  • Tests…

Et on va voir tout ça dans l’article.

#Le vrai pouvoir du BDD

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 :

  • Le client : Qui a des besoins réels et s’est imaginé un résultat ;
  • Les développeurs : Qui vont construire ce qu’ils ont COMPRIS de la problématique du client.

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.

#BDD pour Behavior-Driven Development

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.

#BDD pour programmation pilotée par le comportement

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.

Behavior-Driven Development : Critère d'acceptations vs Scenario
https://www.youtube.com/watch?v=0A4NiBTmx2o

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 ?

#Behaviour-Driven Development ou Behavior-Driven Development

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.
« Behaviour » est épelé ainsi chez les Britanniques, alors que « behavior » est employé par les Américains, et semblerait-il, le reste du monde.

https://ell.stackexchange.com/questions/202548/what-is-the-difference-between-behavior-and-behaviour

#BDD, comment ça marche ?

Le cycle de BDD se décompose en 3 étapes que l’on verra juste après dans des sections dédiées :

  • Discovery
  • Formulation
  • Automatisation

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).

Les 3 amigos ou les 3 amis

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.

3 amis : utilisateurs, technique, personnes du métier
https://www.slideshare.net/Brunty/bdd-behat-for-phpuk
3 amis construisent la vision commune (le centre du cercle)
https://www.slideshare.net/Brunty/bdd-behat-for-phpuk

Les 3 amis sont des personnes qui ont les rôles suivants :

  • Business (le représentant métier) : Définit le problème ou la fonctionnalité attendue, a besoin de réponses, défini la valeur business (Product Owner, Business Analyst sont aussi dans la boucle) ;
  • Développeurs : Suggèrent un moyen de corriger ce problème ou de créer la fonctionnalité ;
  • Utilisateur / Testeur : Challenge tout le monde sur ce qui est attendu (cherche les ennuis).

En théorie à la fin de la réunion des 3 amis, tous les partis prenants doivent avoir atteint leur but.

Une fois que tout le monde s’est bien assuré que tout le monde se soit bien compris aux travers des exemples, on peut :

  • Commencer les développements (méthode de développement classique)
  • Écrire les tests (Test First ou la méthode TDD)

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…

Tests manuels sur une fonctionnalité sans BDD
Cahier de recettes pour des tests manuels sur une fonctionnalité (sans utiliser de Behaviour-Driven Development)

#Principes et pratiques du Behavior-Driven Development

En BDD, il faut avoir au centre du terrain les parties prenantes.

Souviens-toi du premier principe de la méthodologie agile :

Manifeste Agile principe 1
Manifeste Agile principe 1

Pour résumer, ce qu’est le Behavior Driven Design, on peut s’appuyer sur les actions suivantes :

  • Établir le but de la fonctionnalité ;
  • Inclure toutes les parties prenantes dans sa réalisation ;
  • Décrire la finalité souhaitée à l’aide d’exemples de ce qu’on veut ;
  • Automatiser ces exemples pour fournir une documentation vivante via nos tests d’acceptances le plus tôt possible pour éviter de perdre du temps ;
  • Éviter de payer le prix en production d’éléments qui n’étaient pas clairs (bug ou features inutiles).

Voici comme cela se caractérise en un diagramme :

Pratiques de BDD depuis un diagramme
https://cucumber.io/docs/bdd/

#BDD vs TDD

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.

Exemple TDD en français avec FizzBuzz
https://www.youtube.com/watch?v=nbSaq_ykOl4
Quelle est la différence entre BDD et TDD ?

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.

Peut-on utiliser TDD avec BDD ?

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.

Quelle est la différence entre Given, When, Then et As… I… So that ?

Le canevas « Given, When Then » décrit un scenario, « As, I, So that » décrit un critère d’acceptation.

#Behaviour-Driven Design

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.

#Pourquoi faire du Behavior Driven Development ?

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.

Demande de nouvelle fonctionnalité sans BDD sous Shortcut
Exemple de fonctionnalité demandée

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.

#Living Documentation

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.

Behavior-Driven Development avec Gherkin et l'arborescence des feature files
Feature Gherkin utilisée pour de la documentation vivante en Behavior-Driven Development

Ceci nous a permis de transmettre des exemples détaillés à la future équipe…

Afin qu’elle comprenne mieux le comportement de l’application.

#BDD pour les tests unitaires et fonctionnels

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.

Résultats tests unitaires sans utiliser BDD avec Jest en Javascript
Résultat des tests unitaires lancés avec Jest sur l’excellent projet de Beelance !

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.

BDD n'est pas synonyme de tests avec Cucumber
Lancer des tests avec Gherkin via Cucumber ne fait pas que tu utilises le BDD

Danger des tests liés au BDD

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.

#Avantages de BDD ✅

  1. Retranscrire le besoin métier avec précision
  2. S’assurer que le besoin se retrouve dans le code grâce aux tests
  3. La documentation est vivante car elle évolue avec le code
  4. Trouver rapidement les incohérences dans les règles de gestion
  5. Couvrir un maximum de cas d’usages pour éviter les futures erreurs en production
  6. L’ensemble des acteurs connait réellement la fonctionnalité

#Inconvénients de BDD ❌

  1. Souvent incompris
  2. Réduit à sa seule fonctionnalité de test
  3. Pas assez concentré sur la méthodologie fonctionnelle (la découverte puis la reformulation du besoin)
  4. Mal fait car demande de l’expérience
  5. Pas toujours compréhensible par l’équipe business
  6. Lourd à implémenter au début
  7. Temps d’apprentissage (aussi un avantage car cela permet de mieux cerner le besoin métier)

#Behaviour-Driven Development (1) : Discovery

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 ? 😅

#Faire connaître le besoin

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.

Exemple de tests manuels sans utiliser le Behavior-Driven Development
Tests manuels sans BDD dans le cadre de la rédaction des spécifications fonctionnelles d’un ticket

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…

#Tests d’acceptances / acceptations et user-stories

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).

Template de tests fonctionnels sur GitLab
Template de test pour les merge requests des développeurs

#Template d’une user-story

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…

#Behaviour-Driven Development (2) : Formulation

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.

#Gherkin : Le Domain-Specific Language (DSL)

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.

Langage ubiquitaire en DDD avec la conception technique et la conception métier
À gauche le métier, à droite le développeur, au milieu ceux sur quoi ils s’entendent tous les deux.

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…

Exemple de test unitaire avec Jest en Javascript
Exemples de tests unitaires avec Jest en Javascript

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).

#Exemples de DSL en Anglais et en Français

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 ?

Exemple en anglais d’une fonctionnalité Gherkin

Exemple en français d’une fonctionnalité Gherkin

Scenario : Exemples simples

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 :

Exemple scenarios simples en Behavior-Driven Development par Dan North
https://dannorth.net/whats-in-a-story/

Scenario Outline : Tester plusieurs valeurs

Afin de gagner du temps, on peut être tenté d’utiliser un Scenario Outline (un tableau) afin de rentrer les valeurs attendues.

Ces tables peuvent être aussi grandes qu’on le souhaite (on verra des exemples concrets plus bas).

Exemple Scenario Outline en Behavior-Driven Development
https://jenisys.github.io/behave.example/tutorials/tutorial07.html

#Règles pour de bonnes features

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.

  1. Être concret
  2. Utiliser les mots du business
  3. Abuser du langage commun pour écrire les scénarios (tout le monde doit se comprendre)
  4. Servir les besoins métiers
  5. Donner du contexte pour chaque action (pourquoi on fait ça ?) grâce aux user-stories
  6. Tout le monde valide ces fichiers et ils deviennent LA source de vérité
  7. Tuer les questions et les ambiguïtés
  8. Donner du détail sur tout ce qui n’est pas clair
  9. Utiliser « should » dans le comportement pour clarifier la volonté de la fonctionnalité
  10. Utiliser « ensure » pour différencier les résultats des effets secondaires induits par la fonctionnalité

#Scenario : given, when, then

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.

Given / Étant donné

L’état général du système, le contexte sur lequel on se trouve.

When / Lorsque

Ce qu’on essaye de faire, le comportement de l’utilisateur.

(Elle est généralement là, la valeur de la feature.)

Then / Alors

Changement de l’état, c’est le résultat que l’on souhaite en fonction de la valeur que l’on ajoute.

And / Et

Permet de lier des phrases entre elles que ce soit avec Given, When ou Then.

#Template d’une user-story avec scenarios

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        |

Tests d’acceptations vs Scenarios

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.

#Outils pour communiquer avec les équipes

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.

Conversational patterns

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

  1. À tous les membres de l’équipe de s’approprier le besoin ;
  2. Débusquer les incohérences le plus tôt possible ;
  3. Moins de perte de temps en communication comme tout le monde est dans la boucle ;
  4. On garde la motivation des équipes car tout le monde est impliqué.

Le mode interview des personnes du métier fonctionne aussi très bien pour capter le besoin.

Context Questioning

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 😈

Outcome Questioning

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/

Example Mapping

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.

Example Mapping BDD
https://cucumber.io/blog/bdd/example-mapping-introduction/

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 !

#Behaviour-Driven Development (3) : Automatisation

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 !

#Acceptance-test driven design

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 ?!

Behave pour faire du Behavior-Driven Development technique avec de l'automatisation
Fichiers de test Gherkin passent les tests avec succès sur Behave 😍

#Scenario

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.

#Step definitions

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.

Résultat de tests Behavior-Driven Development lancés avec Cucumber en HTML
Rapport Cucumber sur les tests lancé avec Gherkin en mode BDD

#Organisation des .features

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 :

  • compte non trouvé,
  • compte désactivé,
  • bon mot de passe,
  • mauvais mot de passe.

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

#Tests BDD sans Gherkin ?

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 :

  • Terminer le nom de la classe par Behaviour ;
  • Commencer le nom de chaque fonction par should ;
  • Se concentrer sur le prochain comportement le plus important à tester pour prioriser les tests ;
  • Chaque nom de fonction doit format une phrase compréhensible en camelCase.

Et je trouve que c’est exactement vers cela que l’on doit se diriger.

Tests en Behavior-Driven Development sans Gherkin
Fonction de test en BDD sans Gherkin

#Tests e2e

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.

Base de données Neo4J visualisée sous forme de Graph avec ses relations
Base de données Graph (Neo4J) avec des milliers d’enregistrements et leurs relations

Tests e2e avec Behave en Python

Voici ce que nos tests e2e ont donné avec Gherkin et Behave (en Python).

Et la partie qui s’occupe d’attaquer l’API.

#Comment faire du Behavior-Driven Development dans ses projets ?

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).

Behavior-Development Flow pour créer les features
Flow de développement inspiré du BDD et du DDD chez Beelance

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…

#Comment échouer avec BDD ?

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.

Se concentrer sur l’apparence

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.

Test UII avec Behavior-Driven Development sur la page de Wikipédia
Bouton rechercher sur Wikipédia dans un but de test avec BDD.
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.

Exemple de test e2e avec Behat et Mink
Voici un exemple de test e2e avec Behat et Mink : https://docs.behat.org/en/v2.5/cookbook/behat_and_mink.html

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 !

Des scenarios trop long

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.

Ne pas fournir d’exemples précis

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 requis

La règle de gestion semble simple…

Mais l’exemple fourni ne comporte rien qui puisse être utilisé pour tester cette règle.

  • A quel âge puis-je acheter de l’alcool ?
  • Que se passe-t-il si je suis accompagné ?
  • Puis-je venir chercher une commande au Drive avec de l’alcool dedans ?

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 Behavior-Driven Development

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. 👇

#Livre : Open-Source sur le Behavior-Driven Development

Ils donnent une bonne approche du BDD.

  • Du point de vue du business
  • Du point de vue des développeurs
Livre sur le Behavior Driven Development
https://github.com/Halleck45/livre-developpement-pilote-comportement

#Livre : Software craft: TDD, Clean Code et autres pratiques essentielles

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.

Livre Software Craft
Software craft: TDD, Clean Code et autres pratiques essentielles

En plus, le livre a été écrit par des français. 🇫🇷

#Vidéo : Matt Brunt – Behaviour Driven Development and Behat: Telling Stories Through Code

J’ai trouvé cette conférence ultra-stylée, elle m’a donné envie de pratiquer BDD encore plus que maintenant.

https://www.youtube.com/watch?v=bCLlBgYQoIk

#Vidéo : Cucumber – Discovery: The first practice of Behaviour-Driven Development

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.

https://www.youtube.com/watch?v=JuWEQsE7Hlo

#Vidéo : WealCome – BDD, DDD, ATDD et TDD expliqués !

Une masterclass sur BDD, DDD, TDD…

Franchement, à regarder.

https://www.youtube.com/watch?v=jxBmKvS7lAo

#Présentation de Liz Keogh sur le “Behavior Driven Develoment »

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. 😊

#Conclusion

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 ?

👩‍💻 Réagir à cet article 👨‍💻

Merci de partager ton histoire avec la communauté !