BreizhCamp : Behaviour Driven Development par Olivier Billard et Thierry Henrio
Pour cette session, Olivier et Thierry nous ont présenté le Behaviour Driven Development (BDD) en découpant la session en trois grosses parties :
- Tout d’abord, Thierry, en se basant sur sa propre expérience, nous a présenté comment il en était arrivé à faire du BDD,
- puis Olivier nous a présenté plus précisément ce qu’était le BDD,
- enfin, Thierry et Olivier nous ont présenté certains outils tels que GreenPepper, JBehave et Cucumber.
C’est cette passionnante session que je vais tenter de vous retranscrire dans la suite de ce billet…
Pourquoi le BDD?
Dans cette première partie, Thierry nous a expliqué comment il était venu à faire du BDD.
Tout a commencé en 2005 où dans une logique de code se voulant plus sûr, Thierry utilisait la méthode TAD (Test After Development) qui n’est pas en tant que telle une méthode, mais qui avait, au moins, l’avantage de tester le code écrit et que cela valait mieux que de ne rien avoir du tout. Cependant, cela s’avérait long à mettre en place (écrire un test à postériori n’est pas chose toujours aisée) mais également prenait un certain temps lors de la phase de compilation/test. En effet, ces tests s’avéraient être plus souvent des tests d’intégration. En outre, les tests s’avéraient régulièrement KO, soit en raison d’un système externe non disponible, soit en raison de modifications dans le code. Bien sûr, le terme long ne veut pas dire grand chose et est très subjectif et c’est pourquoi Thierry est venu à la conclusion qu’il fallait comprendre la cause racine. En effet, en plus du fait que le passage du test prenne du temps, cela impactait également la productivité du développeur qui faisait son code, faisait ses tests, lançait ses tests en local, mergeait son code avec celui du SCM puis relançait ses tests et enfin pouvait pousser son code sur le SCM. Si on y ajoute que l’exécution des tests peut prendre entre 5 et 10 minutes (dans un cas optimiste), le calcul était vite fait…
Du coup, Thierry est venu à s’intéresser plus précisément à ce qu’était un Test Unitaire (TU) et nous l’a donc résumé en ces termes :
Un test n’est pas unitaire si :
- il touche la base,
- il touche le réseau,
- il touche un fichier,
- il a des effets de bords sur les autres tests lorsqu’on les lance tous,
- il nécessite la modification d’une configuration pour s’exécuter.
Et en 2007, en pensant plus TDD (Test Driven Develoment) et en utilisant des framework de tests tels que EasyMock, Mockito ou JMock, il a réussi à diminuer ses temps d’exécution de test à 2-3 minutes mais également à mieux concevoir.
Par contre, un écueil existait toujours : le client n’était toujours pas satisfait… Du coup, après approfondissement sur le sujet TDD, Thierry est tombé sur la citation de Dan North suivante (http://behaviour-driven.org/GettingTheWordsRight) :
As an example, when I was first getting to grips with TDD, I was pairing with an experienced agile coach, writing little test methods, then writing the code, and generally feeling good about life. Then I went ahead and wrote some code without a test. The coach, JR, asked me why I’d written the code. I answered: “we’ll need it in a minute”, to which JR replied “yes, we might”. By using the word “might”, he introduced the possibility that we might not. As it turned out, we didn’t.
En gros, on écrit des tests qui serviront peut être à tester du code… ou pas… et que parfois, ils n’apportent absolument aucune valeur ajoutée.
Là encore, déception ! Le TDD n’était pas la solution ultime… En plus du fait que les tests unitaires ne satisfassent pas complètement le client, ils peuvent parfois ne rien apporter…
I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls (Dan North)
La suite logique du TDD étant le BDD (Behaviour Driven Development), Thierry a cherché dès 2008 à voir comment cela pouvait rendre le client “heureux”.
En fait, le principal objectif du client est qu’on lui rende un produit qui réponde à ses attentes qu’il expose généralement à l’aide de scénarii fonctionnels qui peuvent être formalisés de la manière suivante :
As a [role],
I want [behavior]
In order to [outcome]
Or le BDD tend à chercher la valeur que peut avoir un scénario pour le client qui peut alors s’exprimer de la manière ci-dessous :
In order to [outcome]
I want [behavior]
On y constate, que même si le résultat est identique, cela permet de mettre en avant la valeur que recherche le client.
En conclusion de cette partie, Thierry nous a donc présenté son évolution qui avait permis de passer du TAD au BDD.
Mise en oeuvre du BDD
Après la présentation de Thierry sur l’origine et les concepts du BDD, Olivier nous a présenté comment il était possible d’industrialiser son code pour prendre en compte cette nouvelle composante.
Par exemple, suite à la phase de discussion avec le client qui a permis de mettre en avant de la valeur mais également à formaliser, via un langage commun, les tests (ou scénarii), il est nécessaire de les reporter sur un support. Et là, il est possible, en fonction du client, soit d’utiliser un outil de type wiki, soit de le formaliser dans un simple fichier texte. Bien sûr, l’objectif est que ces scénarii servent à valider l’application produite et plus précisément l’implémentation des règles métiers.
Dans ce cas, on dit que l’on fait du TDR (Test Driven Requirements).
Par contre, autant pour faire du TDD, il était préférable de posséder certains outils (comme JUnit, Mockito, EasyMock, …), autant, le TDR propose ses propres outils qui possèdent chacun leurs avantages et inconvénients :
- Fit
- FitNesse + Fit
- FitNesse + Slim
- GreenPepper
- Twist
- JBehave
Ces outils permettent donc de décrire le comportement en terme de scénario sous la forme suivante :
- Given : le contexte initial
- When : un évènement arrive
- Then : qui produit un certain résultat attendu
Suite à cette partie, Olivier et Thierry nous ont présenté de manière plus détaillée GreenPepper, Cucumber et JBehave.
Je ne détaillerai pas cette partie mais l’idée qu’ils proposent est de lier le code à exécuter au comportement décrit dans un langage plus naturel (par exemple, JBehave permet via des annotations d’associer un élément de la story à la méthode à exécuter alors que GreenPepper permet de stimuler le System Under Test (SUT) avec des fixtures spécifiques aux besoins).
Conclusion
Pour conclure, Olivier et Thierry ont fini la session par ces différents points :
- Le BDD permet de se focaliser sur la réponse aux attentes du client.
- Il permet de livrer du code fonctionnel.
- Il permet de formaliser la communication avec le client en utilisant un langage commun.
- Le BDD n’est pas un outil mais une méthodologie de travail.
Licence
Sauf mention contraire, le contenu de ce blog est mis à disposition selon les termes de la licence Creative Commons.