Blog Arolla

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

A l’occasion de la release 1.0.7 du plugin Eclipse pour JBehave, je vais en profiter pour présenter cet outil, à quoi il peut servir et comment le mettre en oeuvre.

JBehave est un framework BDD pour Java et Groovy.

BDD quézako!?

Tout d’abord un peu d’histoire: le BDD encore un acronyme du type xDD? Et bien oui, encore un! Le BDD (Behavior Driven Development) est présenté comme une évolution du TDD (Test Driven Development).
Proposé par Dan North (qui fut aussi l’un des initiateurs du projet JBehave), le BDD consiste à étendre le TDD en écrivant non plus du code compréhensible uniquement par des développeurs, mais sous forme de scénario compréhensible par toutes les personnes impliquées dans le projet.

Autrement dit, il s’agit d’écrire des tests qui décrivent le comportement attendu du système et que tout le monde peux comprendre.

Et le rapport avec le TDD? Eh bien généralement, ces scénarios sont écrits et définis avant que l’implémentation ne commence. Ils servent à la fois à définir le besoin mais également vont guider le développement en le focalisant sur la fonctionnalité décrite. Dans l’absolu, on continue à faire du TDD mais on ajoute en plus l’expression du besoin en langage naturel. Alors que le TDD garantit d’une certaine façon la qualité technique d’une implémentation, il ne garantit pas la qualité fonctionnelle. Plusieurs éléments peuvent ainsi être techniquement valides mais une fois mis ensemble, ils ne répondent pas du tout au besoin réellement exprimé par le client. De manière un peu caricaturale, le BDD va guider le développement d’une fonctionnalité, tandis que le TDD guidera son implémentation.

Les avantages d’une telle pratique sont multiples (les différents « points » réfèrent à la figure ci-après):

Point (1): Un dialogue restauré

  • L’écriture des scénarios se fait de manière collective: développeurs, clients, équipe support, …: tout le monde peut participer à l’expression du besoin, puisque celui-ci se fait en langage naturel. Toutes les questions soulevées, par le client ou par le développeur, peuvent faire l’objet de scénarios dédiés. Les scénarios décrivent alors le fonctionnement réel de l’application, et le traitement des cas aux limites.

BDD un dialogue

  • En illustrant chaque cas d’utilisation par des exemples concrets, les règles métiers sont moins abstraites et mieux comprises.
  • En écrivant des tests que tout le monde peut comprendre, les clients s’assurent que les développeurs ont bien compris les besoins métiers, les développeurs sortent de leur “autisme” (Herding Code #42 ~ Scott Bellware on BDD) et se rapprochent du métier. Les deux parties avancent ensemble dans la même direction. Cela constitue un véritable outil de communication rapprochant développeurs et personnes du métiers, et restaure la confiance du client en rendant le comportement explicite et visible.
  • A chaque fois qu’une nouvelle spécification est écrite, son utilisation est illustrée par plusieurs exemples et cas de tests: cela force à réfléchir sur la fonctionnalité et son utilisation. Il est possible de communiquer avec tout le monde et pas seulement les développeurs, il est ainsi plus facile d’inciter les gens à s’impliquer sur ce qui est fait: d’avoir des fonctionnalités mieux décrites et plus challengées. Cela permet aussi de rassurer le développeur sur l’intérêt de ce développement.
  • En utilisant le contexte métier pour décrire les fonctionnalités souhaitées, il y a moins de digressions et de considérations techniques dans l’expression des besoins: a-t-on besoin de savoir qu’un message d’erreur sur une interface Web est un élément HTML avec la classe ‘error’? Non, on souhaite seulement s’assurer qu’en cas de saisie erronée, un message d’erreur est présent et ce, dans le contexte d’une page web. Le contexte métier sert alors de filtre dans l’expression des besoins, libérant le développeur et les personnes du métier de détails techniques et d’implémentation.
  • Le scénario sert à focaliser les discussions et la réalisation sur les attentes du client. En guidant  l’écriture du code, celui-ci devient plus fonctionnel et plus imprégné du métier.
  • La structuration du scénario permet de formaliser l’expression des besoins avec un langage commun et facilement interprétable. Ces mots clés (Given, When, Then, As a, In order to …) permettent de définir une grammaire commune qui sert à la fois à structurer le scénario en langage naturel, et sert aux outils comme JBehave à faire la correspondance avec le code.

BDD apperçu général

Point (2): Un développement guidé et documenté

  • Le besoin fonctionnel guide le développement de l’application: on développe ce dont on a besoin; et on limite les écueils de cathédrale technologique.
  • Les comportements deviennent documentés: même si la javadoc ou les commentaires permettent de documenter le code, il existe rarement de documentation sur le comportement réel de l’application; on dispose ainsi d’exemples concrets.
  • Les tests unitaires sont généralement très riches sur le comportement d’une application, mais ils restent très hermétiques à des non-développeurs (parfois même aux autres développeurs et aux nouveaux arrivants), en les rendant plus accessibles et plus lisibles, ils constituent une réelle source d’information sur le comportement de l’application, et sont toujours à jour.

Point (3): Une documentation à jour et toujours disponible

  • En étant directement exécutables, les histoires intègrent directement la base de code: elles sont archivées avec le code qui les exécute. Les histoires et leurs modifications évoluent donc naturellement en même temps que la base de code. Avec un astucieux jeu de tag et de branche, on peux donc facilement documenter les évolutions fonctionnelles du code.

Point (4): Des tests en continu sur les fonctionnalités

  • Ce point rejoint très fortement les points précédents: l’environnement d’intégration continue teste en permanence les comportements fonctionnels réels au fil des modifications du code, et non plus seulement l’implémentation technique.

Si l’on devait résumer en une phrase:

Il s’agit d’une méthodologie de travail, permettant d’écrire des tests compréhensibles à la fois par le client et par le développeur et s’intégrant directement dans la base de code.

On notera que l’on parle bien de tests au sens général! Cette méthodologie peut en effet aussi bien s’appliquer à des tests unitaires, des tests fonctionnels, des tests d’intégrations, des tests de bout en bout, etc. Quelle que soit la taxonomie utilisée, tout type de test pourrait s’exprimer à l’aide de scénario.

Il s’agit d’ailleurs d’un travers que l’on rencontre souvent: associer systématiquement cette méthodologie avec l’écriture de tests d’intégration. Si l’on évoque JBehave, pour beaucoup l’association est rapidement faite avec Selenium et l’écriture de tests d’intégration d’interface Web.

Démystification Eh bien non! Tout type de tests peut s’écrire avec les principes évoqués. En fait, la plupart des outils de BDD (JBehave, Cucumber, Easyb, …) ne font « que » la traduction d’un scénario en langage naturel en appels de méthodes. Ce que les méthodes pilotent réellement tient uniquement de leur contenu et non de l’outil utilisé pour les appeler. Les outils définissent une grammaire permettant de faire correspondre le scénario avec le code qui sera appelé. Chaque étape est généralement reliée à une fonction ou une méthode particulière qui pilote un changement d’état ou une action.

BDD la traduction d'une story en appel de code

De plus, il est tout à fait possible (et même fortement conseillé) d’utiliser ce type de tests même si ceux-ci ne guident pas le développement et sont écrits a posteriori: la source documentaire qu’ils procurent est presque aussi riche que le code qu’ils manipulent.

Formalisme et structure des histoires

Structure d'une histoire

Avant d’illustrer cela par quelques exemples, voyons le formalisme standard utilisé pour écrire ces scénarios.

Tout d’abord le préambule ou Narrative.
Il s’agit de l’entête d’une histoire qui est commun à un ensemble de scénarios. Il permet de placer le contexte général et de décrire très brièvement les fonctionnalités qui vont être présentées. En général, ce préambule n’est qu’illustratif et ne pilote pas de code.

As a [rôle], En tant que [rôle ou personne],
I want [behavior] Je veux [fonctionnalité]
In order to [outcome] Afin de [but, bénéfice ou valeur de la fonctionnalité]

Une histoire étant constituée d’un ou plusieurs scénarios, vient ensuite la description sommaire du scénario qui va être déroulée, son titre:

Scenario: [scenario] Scénario: [description]

Enfin le contenu du scénario. Le scénario est une succession d’étapes (Step) permettant:

  • soit de définir et de construire le contexte dans lequel le scénario va se dérouler Given,
  • soit de provoquer des événements ou des actions sollicitant le système When,
  • soit de vérifier que le comportement attendu a bien eu lieu Then; c’est généralement à ces étapes que l’on retrouvera les assertions.
Given [an initial context] Etant donné [un contexte initial (les acquis)]
When [action] Quand [un événement survient]
Then [expected result] Alors [on s'assure de l'obtention de certains résultats]

Cette grammaire (à base de mots clés en début de phrase) permet de définir le langage de nos scénarios. Il est de plus en plus souvent appelé langage Gherkin, nom donné et popularisé par le framework Cucumber (voir Cucumber-jvm pour un « portage disutable » en Java).

Flash info !

Excusez-nous pour cette interruption de programme, voici quelques actualités:

Et la réponse de Dan North: BDD is like TDD if….

That’s all Folks (pour aujourd’hui!)

Nous venons de voir ce qu’est le BDD et son formalisme, avant de poursuivre faisons une petite pause pour digérer tout cela. Dans notre prochain article, nous verrons comment mettre tout cela en œuvre en codant un exemple très simple avec JBehave.

4 comments for “Le BDD, qu’est ce que c’est?

  1. 20 juin 2012 at 9 h 48 min

    Merci Arnauld pour cet excellent article. Impatient de découvrir la suite!

  2. Gamal
    20 février 2014 at 10 h 29 min

    En quoi la méthode BDD et l’écriture de User Stories diffèrent ?

  3. 22 février 2014 at 0 h 28 min

    Coucou Gilles,

    La méthode BDD est fondée sur la collaboration des parties prenantes. En travaillant de manière collaborative, le métier, les testeurs et les développeurs s’assurent de bien comprendre le besoin exprimé en allant même jusqu’à le challenger.
    De ces discussion, le besoin est mieux compris et élicité aux travers de plusieurs exemples. La mise en oeuvre de ces exemples peux nécessiter la réalisation de plusieurs User Stories. Et inversement, une User Story peut être complétée par plusieurs examples/scénario.

    Pour citer Ron Jeffries: « Une user story est la promesse de discussion », cette discussion permet de s’assurer que ce qui est décrit est compris de tous, et l’un des moyen est de fournir des exemples concrets.

    D’autre part, si l’on va jusqu’à l’automatisation des exemples, ces exemples deviennent une documentation vivante de l’application, alors que la User Story décrit le comportement d’un fonctionnalité à un instant donné. La documentation, issue directement de l’execution des exemple, vit au rythme de l’application. La description d’une User Story n’est que la capture d’un besoin potentiellement éphémère et aussitôt remplacé et rendu obsolète par les User Stories suivantes.

    Une User Story est pour moi un média de planification/priorisation qui vient rapidement nourrir les limbes oubliées de la colonne « Done ».

    Les deux sont donc bien complémentaire et la pratique de BDD peux aider à définir les User Stories nécessaires à la réalisation d’une fonctionnalité.

    //Arnauld

Laisser un commentaire

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

* Copy This Password *

* Type Or Paste Password Here *