Le Behavior Driven Development (BDD) [60] est une pratique agile invent´ee en 2003 pour r´epondre `a la difficult´e de mettre en place une approche Test First de bout en bout (Test Driven Development [8]). Le Test Driven Development est une bonne pratique agile venant d’eXtreme Programming [9]. Kent Beck propose de l’utiliser de fa¸con intensive jusqu’`a sp´ecifier par des tests avant de coder.
Si l’id´ee parait s´eduisante au d´epart, elle est tr`es difficile `a mettre en œuvre. Nous introduisons le BDD comme une alternative au TDD, puis nous explicitons l’approche BDD et pr´esentons les outils et frameworks associ´es.
2.2.1 Le BDD, une alternative au Test Driven Development
La principale difficult´e lors de l’utilisation du TDD concerne le manque de r`egles claires sur ce qu’il faut tester ou non. Il est possible d’obtenir un code passant tous les tests dans une approche TDD et ne passant pas les tests d’acceptation pour la fonctionnalit´e `
a d´evelopper. Un autre difficult´e concerne la granularit´e des tests unitaires. Faut-il faire des tests unitaires pour une m´ethode, un composant, une fonctionnalit´e ? Pour r´esoudre ces probl`emes, le BDD propose de faire en sorte que les cas de test d´ecoulent des crit`eres d’acceptation d’une histoire utilisateur (user story).
Un logiciel d´evelopp´e grˆace aux m´ethodes Agile est d´ecoup´e en user stories. Ces user stories d´ecrivent les besoins fonctionnels du produit d’un point de vue utilisateur. Le BDD propose de faire correspondre `a chaque user story un ensemble de sc´enarios illustrant les cas d’utilisation de la fonctionnalit´e qu’elle d´ecrit. Ces sc´enarios sont ensuite transform´es en tests ex´ecutables. Il y a donc continuit´e entre les besoins et exigences d’un produit et les cas de test les validant. De ce fait, le BDD permet une tra¸cabilit´e entre une exigence fonctionnelle et les cas de test qui la couvrent.
Dans l’approche BDD, un sc´enario de test utilise le vocabulaire de la description d’une user story. Les noms choisis pour les sc´enarios de test doivent s’apparenter `a des phrases compl`etes. Selon Dan North [60], la phrase d´ecrivant un sc´enario de test devrait commencer par le mot should (doit) pour aider son concepteur `a se concentrer sur l’intention du
sc´enario. De plus, les interfaces de d´eveloppement se focalisent uniquement sur les tests `a ex´ecuter et peuvent elles aussi s’adapter au domaine m´etier. Ainsi, la compr´ehension des tests et du code v´erifiant les tests est simplifi´ee pour toutes les personnes impliqu´ees dans le d´eveloppement de l’application.
Le BDD est un sous-ensemble des pratiques ATDD qui sont aussi nomm´ees Story Test Driven Development (SDD) ou sp´ecification par l’exemple. Ces m´ethodes ont ´et´e popula- ris´ees `a partir de 2004 grˆace aux outils Fit et FitNesse1, malgr´e les objections de Kent Beck en 2003 dans Test Driven Development : By example qui avait jug´e ces m´ethodes inexploitables [8]. De fait, le TDD n’est qu’une des pratiques propos´ees par l’eXtreme Pro- gramming. La pratique du TDD est d´edi´ee aux d´eveloppeurs, tandis que la pratique du BDD implique toute l’´equipe de d´eveloppement, y compris le client.
2.2.2 L’approche BDD
Nous avons vu que la m´ethode BDD utilise les user stories comme point de d´epart lors de la sp´ecification fonctionnelle d’un produit [21]. L’approche BDD promue par Dan North s’est inspir´ee du Domain Driven Design et de son concept de langage ubiquitaire [34] qui tend `a unifier un langage commun entre experts m´etier et d´eveloppeurs. Par son approche, le BDD acc´el`ere l’´emergence d’un langage omnipr´esent. De plus, l’approche BDD se base sur un langage ubiquitaire d´edi´e `a l’analyse des besoins. Elle apporte deux patrons g´en´eriques pour d´efinir une user story et les sc´enarios correspondants quel que soit le domaine m´etier. Le premier patron se focalise sur la fonctionnalit´e en elle-mˆeme repr´esent´ee par une user story. Elle est support´ee par la syntaxe suivante [61] :
T i t l e : [ one l i n e d e s c r i b i n g t h e s t o r y ] As a [ r o l e ]
I want [ f e a t u r e ] So t h a t [ b e n e f i t ]
Cette syntaxe identifie l’utilisateur principal de la fonctionnalit´e ainsi que les b´en´efices attendus. Interconnecter l’utilisateur et les b´en´efices d’une user story permet d’expliciter pour qui est faite la fonctionnalit´e et pourquoi l’utilisateur en a besoin.
Une des caract´eristiques principales du BDD [75] est de se concentrer sur la description du comportement souhait´e d’une fonctionnalit´e ou d’un syst`eme, par des sc´enarios de test qui automatisent la validation de chacune des user stories (crit`eres d’acceptation ex´ecu- tables) et permettent de d´eterminer la fin du d´eveloppement. Pour cela, le BDD propose un deuxi`eme patron qui divise un sc´enario de test rattach´e `a une user story en trois parties. Cette structuration est implant´ee par un langage appel´e Gherkin. Elle est support´ee par la syntaxe suivante :
S c e n a r i o : T i t l e
Given [ c o n t e x t ]
And [ some more c o n t e x t ] . . . When [ e v e n t ]
Then [ outcome ]
And [ a n o t h e r outcome ] . . .
Chaque sc´enario est compos´e d’un nom (Title) d´ecrivant une situation de test particu- li`ere. Le comportement est d´ecrit par trois ´etapes suivant le patron Acteur-Action-Assertion (AAA) des test unitaires en eXtreme Programming. La premi`ere ´etape d´esigne le contexte de test correspondant `a la mise en condition du syst`eme `a tester (Given). L’´etape suivante d´ecrit le ou les ´ev`enements `a traiter et d´ecrit ainsi la fonctionnalit´e attendue (When). La troisi`eme ´etape est compos´ee d’assertions permettant de rendre le test ex´ecutable, voire automatisable (Then). Cependant, Dan North consid`ere que cette ”unitarisation” des tests ne correspond pas `a tout type de syst`eme `a tester, en particulier pour les sites Web et pour les syst`emes avioniques critiques et temps-r´eel, dans notre cas. Il ´evoque la possibilit´e d’en- chaˆıner plusieurs sc´enarios dans un sc´enario, ce qui est exactement le cas pour l’ing´enierie syst`eme avionique o`u chaque suite de tests suit un plan de vol.
Les sc´enarios produits grˆace `a la syntaxe propos´ee par le BDD utilisent le vocabulaire des experts du domaine et des utilisateurs. De plus, les tests ´etant ´ecrits en langage naturel, ils donnent l’opportunit´e aux parties prenantes du projet de s’impliquer pleinement dans la r´ealisation des sc´enarios de test et par la mˆeme de sp´ecifier le comportement attendu du syst`eme `a d´evelopper.
Sans effort d’automatisation, l’approche BDD perd de sa pertinence ; les instructions produites grˆace aux sc´enarios de haut niveau doivent ˆetre transform´ees en tests ex´ecutables. Cette correspondance est r´ealis´ee grˆace `a des m´ecanismes d’expressions r´eguli`eres. Le code n´ecessaire entre le sc´enario de test en langage naturel et le code ex´ecutable s’appelle du code glu (glue code).
2.2.3 Outils et framework BDD
Le d´eveloppement par l’approche BDD est support´e par des outils sp´ecifiques. Il existe actuellement plus d’une trentaine d’outils de ce type d´evelopp´es pour des langages de programmation diff´erents (PHP, Java, JavaScript, Ruby, Scala, C#, Delphi/Pascal, Groovy, etc.). Nous pr´esentons succinctement les outils les plus connus comme JBehave, Cucumber, RSpec.
Le plus connu est JBehave car le co-administrateur de l’´equipe de d´eveloppement est le pr´ecurseur de l’approche BDD [48]. ´Ecrire des tests avec JBehave revient `a d´ecrire les sc´enarios des comportements attendus pour chaque fonctionnalit´e. Un lien est ´etabli avec le code `a tester grˆace `a des expressions r´eguli`eres. Les tests peuvent ˆetre ex´ecut´es par plusieurs s´equenceurs, `a la fin de chaque ex´ecution un rapport de test sera produit.
Contrairement `a JBehave uniquement centr´e sur le langage Java, Cucumber supporte une grande partie des langages de programmation classiques [24]. Les m´ecanismes propos´es
sont identiques `a ceux de JBehave. Des tests d’acceptation par les interfaces sont possibles par l’utilisation du framework Selenium [27].
RSpec, quant `a lui, a ´et´e sp´ecialement d´evelopp´e pour Ruby et son slogan reprend la philosophie initiale du BDD : rendre le TDD productif et amusant [65]. Le langage ubiquitaire utilis´e pour les tests d’acceptation est un peu diff´erent de celui propos´e par le BDD, le patron Given-When-Then ´etant remplac´e par Describe-Context-It.