Autrefois, la gestion de la qualité demandait plusieurs semaines pour contrôler les fonc­tion­na­li­tés d’un logiciel finalisé. Aujourd’hui, grâce à des tests au­to­ma­ti­sés lancés sur pression d’un simple bouton, il est aisé de vérifier si une ap­pli­ca­tion complexe remplit ses fonctions. Le Behavior Driven De­ve­lop­ment ou BDD est une technique qui a le vent en poupe. Cette forme de dé­ve­lop­pe­ment de logiciel agile découle du Test Driven De­ve­lop­ment (TDD) et est con­si­dé­rée comme sa suite logique. À la dif­fé­rence du TDD, le BDD considère les logiciels es­sen­tiel­le­ment du point de vue de l’uti­li­sa­teur. Cette approche promeut une con­cep­tion de logiciel globale et facilite la col­la­bo­ra­tion entre les dé­ve­lop­peurs, la gestion de la qualité et les clients.

Qu’est-ce que le Behavior Driven De­ve­lop­ment ?

Avec la com­plexité crois­sante des ap­pli­ca­tions lo­gi­cielles, de plus en plus de méthodes de gestion de la qualité et de tests se dé­ve­lop­pent. C’est le seul moyen de vérifier de manière fiable la fonc­tion­na­lité des dif­fé­rents com­po­sants et de détecter im­mé­dia­te­ment les erreurs On connaît depuis longtemps le dé­ve­lop­pe­ment piloté par les tests ou Test Driven De­ve­lop­ment (TDD). Dans ce cas de figure, les dé­ve­lop­peurs dé­ve­lop­pent en parallèle des tests unitaires ou des tests système adaptés. Lors du processus de con­cep­tion d’un logiciel, il est pertinent de ne pas seulement pro­gram­mer, mais de faire par­ti­ci­per également les membres de l’équipe ou les acteurs qui ne com­pren­nent pas le code technique. C’est ce que permet le Behavior Driven De­ve­lop­ment (BDD).

Lors du dé­ve­lop­pe­ment d’un logiciel agile, tous les par­ti­ci­pants au dé­ve­lop­pe­ment d’un programme peuvent définir le com­por­te­ment souhaité d’un logiciel avant que le pro­gram­meur n’écrive le texte source, ceci grâce à des des­crip­tions rédigées dans un langage fa­ci­le­ment com­pré­hen­sible, par exemple. Cela signifie que le client pour lequel un logiciel est développé peut également prendre part à la mo­dé­li­sa­tion. Le BDD promeut la col­la­bo­ra­tion et assure une ré­par­ti­tion des res­pon­sa­bi­li­tés. Si cette méthode de dé­ve­lop­pe­ment de logiciel est bien utilisée, elle permet d’éviter des ma­len­ten­dus et génère, dans le meilleur des cas, un produit final de qualité.

Comment fonc­tionne le Behavior Driven De­ve­lop­ment ?

Comme son nom l’indique, le Behavior Driven De­ve­lop­ment s’oriente vers le com­por­te­ment que les logiciels doivent avoir. Grâce au langage ubi­qui­taire, qui signifie gros­siè­re­ment « langage d’usage courant », les profanes peuvent également créer certaines des­crip­tions de com­por­te­ment. Le langage ubi­qui­taire est issu du Domain Driven Design (DDD), qui, comme le BDD, se concentre sur les domaines d’ap­pli­ca­tion. Les deux approches prennent en compte tous les domaines impliqués dans le processus de dé­ve­lop­pe­ment de logiciels et les relient entre eux in­dé­pen­dam­ment des fra­me­works, des langages de pro­gram­ma­tion ou des outils. Cela est rendu possible grâce à l’uti­li­sa­tion d’un langage unifié.

Cependant, le Behavior Driven De­ve­lop­ment n’est pas dépourvu d’outils ou de fra­me­works. En effet, pour que les cas de test que vous dé­fi­nis­sez soient traduits en code exé­cu­table, quelques règles doivent être suivies. Par exemple, les des­crip­tions dans le BDD ne sont pas rédigées en texte libre. En utilisant les outils BDD, tels que JBehave, Cucumber ou Behat, vous suivez une structure définie qui permet une im­plé­men­ta­tion fluide. L’uti­li­sa­tion de ces outils est beaucoup plus facile que l’ap­pren­tis­sage d’un langage de pro­gram­ma­tion classique. Découvrez les struc­tures hié­rar­chiques que vous devez suivre dans le cadre du Behavior Driven De­ve­lop­ment :

  • Commencez par une analyse des besoins afin de définir les tâches, les objectifs et les fonc­tion­na­li­tés du logiciel. Demandez-vous, ou demandez à votre client, ce que le logiciel doit faire.
  • Une fois que vous avez identifié toutes les fonc­tion­na­li­tés, celles-ci sont décrites sous la forme de scénarios pré­dé­fi­nis. Essayez de penser à toutes les si­tua­tions possibles dans les­quelles le logiciel doit réagir avec une réponse précise.
  • L’étape suivante consiste à définir les réponses attendues pour chaque scénario dans un schéma de vé­ri­fi­ca­tion (« étant donné-quand-alors »). « Étant donné » décrit le logiciel avant le test, « quand », l’action pendant le test et « alors » l’état du logiciel après le test.

Selon l’outil BDD utilisé, le vo­ca­bu­laire peut lé­gè­re­ment varier. Certains outils proposent des variantes à la for­mu­la­tion « étant donné ». Ces outils sont dis­po­nibles pour les langages de pro­gram­ma­tion les plus courants, tels que Java, Ja­vaS­cript, Python ou Ruby.

Behavior Driven De­ve­lop­ment : étude de cas

Imaginez que vous vouliez créer une boutique en ligne facile à utiliser. Si le client s’est déjà en­re­gis­tré dans votre boutique, les données uti­li­sa­teurs doivent être en­re­gis­trées. Ainsi, il peut fa­ci­le­ment se re­con­nec­ter sans avoir à indiquer à chaque fois ses données per­son­nelles. Dans le langage Gherkin largement utilisé dans l’outil BDD Cucumber, la syntaxe correcte est la suivante :

Fonctionnalité : un client existant doit pouvoir se connecter à son compte utilisateur avec ses données d’accès
	Scénario : le client saisit les données d’accès correctes lors de la procédure de connexion
		Étant donné que j’ai un compte utilisateur valide
		Et que je me trouve sur la page de connexion du site Web
		Quand j’entre mon adresse e-mail dans le champ prévu à cet effet
		Et que j’entre mon mot de passe dans le champ prévu à cet effet
		Et que je clique sur le bouton de connexion
		Alors je devrais être automatiquement connecté

L’exemple ci-dessus montre que grâce à l’ajout de « et », plusieurs con­di­tions peuvent être posées si­mul­ta­né­ment et vos scénarios peuvent être com­plexi­fiés.

Pro­gram­ma­tion pilotée par le com­por­te­ment : ce qui dif­fé­ren­cie le BDD des autres pro­cé­dures de test

Lors d’un test de logiciel, la pro­gram­ma­tion pilotée par le com­por­te­ment se concentre sur la question « comment ». Les personnes con­cer­nées veulent savoir comment tester cor­rec­te­ment le com­por­te­ment d’un code, et non son im­plé­men­ta­tion. Lors d’un test unitaire, il s’agit de vérifier si une unité de code est cor­rec­te­ment im­plé­men­tée. Cette procédure de test porte donc sur le « quoi » et constitue un moyen rapide de trouver des bugs in­di­vi­duels. La réponse à la question « quand » (quand cela se passe) est donnée par le Test-Driven De­ve­lop­ment, qui est le processus d’exécution des tests. Ce processus peut également contenir des tests unitaires ou d’autres méthodes de test.

Note

Outre les tests unitaires, il existe également des tests d’in­té­gra­tion et des tests fonc­tion­nels. Ceux-ci sont beaucoup plus complexes, car ils portent sur l’in­te­rac­tion des dif­fé­rentes parties du système et sur la fonc­tion­na­lité globale d’un logiciel.

Les avantages et in­con­vé­nients du Behavior Driven De­ve­lop­ment sont compilés dans le tableau ci-dessous :

Avantages In­con­vé­nients
Grâce au langage ubi­qui­taire idéal pour les débutants, aucune con­nais­sance préalable n’est né­ces­saire Des spé­ci­fi­ca­tions mal rédigées com­pli­quent le travail des dé­ve­lop­peurs
Meilleure com­mu­ni­ca­tion entre les dé­ve­lop­peurs, les acteurs et la gestion de la qualité L’in­té­gra­tion d’acteurs allonge le temps de dé­ve­lop­pe­ment
Les scénarios tests servent de do­cu­men­ta­tion pérenne et peuvent être adaptés fa­ci­le­ment La con­ver­sion au flux de travail BDD est complexe pour les codes existants
L’accent est mis sur les uti­li­sa­teurs finaux et la con­vi­via­lité du logiciel  

Bien qu’il vous soit possible d’appliquer chaque méthode de test de façon in­di­vi­duelle, la qualité de votre logiciel sera con­si­dé­ra­ble­ment améliorée si vous utilisez plusieurs méthodes de test en com­bi­nai­son. Le BDD assure un meilleur processus de rédaction des tests, et le TDD une batterie plus complète de tests.

Aller au menu principal