BDD (Behavior Driven Developement)

Le BDD, qu’est ce que c’est ? 

Ce que l’on entend souvent, c’est que le BDD(Behavior Driven Developement) est un langage (Gherkin) permettant par la suite d’écrire les TDD (Test Behavior Developement) .

Faux ! Le BDD est une méthode de travail qui consiste avant tout  à mettre en forme des scénarios de tests dans un langage compréhensible par toutes les parties du projet (techniques ou non).

Oui, parfois (souvent), ces scénarios sont mis sous forme de Gherkin dans un outil comme SpecFlow pour ensuite aller vers du TDD mais il s’agit surtout de communiquer ensemble sur tous les cas possibles d’une fonctionnalité afin de couvrir (fonctionnellement) l’intégralité des possibilités.

« Three Amigos »

Ce que l’on appelle le « Three Amigos » lors d’un atelier BDD, c’est le fait de se mettre autour de la table avec à minima 3 personnes qui porteront une casquette différente pour répondre aux question suivantes :

  • Métier (souvent un BA ou PO): Quel problème essayons nous de résoudre ?
  • Développement (Dev) : Quelle solution pouvons-nous apporter ?
  • Test (QA): Doit trouver les défauts à cette solution pour creuser la totalité des cas et se poser la question du « Et si … ? ».

Exemple :

Métier : « Je veux que mon utilisateur puisse laisser des commentaires »

Développement : « Nous aurons un champs commentaire dans le formulaire »

Test : « Ok, et si l’utilisateur envoie un roman dans le champs ? »

Métier : « Ah mais non c’est logique, on ne veut pas de trop gros commentaires ! »

Développement : « Donc nous dirons 1000 caractères ? »

Métier : « Parfait »

Test : « Et qu’arrivera t-il s’il les dépasse ? »

Métier : « Un message d’erreur ? »

Développement : « Ok ! »

Donnera :

  • Étant donné (Given) qu’un utilisateur laisse un commentaire
  • Quand (When) le commentaire dépasse 1000 caractères
  • Alors (Then) le commentaire ne doit pas être sauvegardé
  • Et ( And) l’utilisateur doit voir un message d’erreur

On ne pense pas tous de la même manière, quelque chose qui paraît évident pour quelqu’un, ne l’est pas forcément pour un autre. Si le BDD n’avait pas eu lieu, le développeur aurait possiblement créé une zone de texte sans limite et le métier serait revenu vers lui plus tard pour la lui demander.

Le BDD permet donc de parer à tout éventualité et de pouvoir anticiper les retours possibles.

On pourrait s’arrêter là, vous avez compris le principe. En atelier, nous mettons sur papier tous ces scénarios afin de partir sur de bonnes bases pour les développements.

Cependant, il existe certains outils permettant d’intégrer ces BDD dans le code pour ensuite en faire des BDD comme « SpecFlow ».

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.