Behavior driven development

Le behavior driven development (BDD) est une approche dans le développement de logiciels agiles issue du développement axé sur les tests (TDD). Il repose sur une approche axée sur l’objet et un design axée sur le domaine (DDD). Le BDD est utilisé principalement dans des projets logiciels complexes car il simplifie l'utilisation d'outils utilisés pour tester les fonctionnalités et la conception du logiciel et de ses interfaces. Le BDD est utilisé dans la création de boutiques en ligne mais n'est pas forcément lié à un cadre unique ou à un langage de programmation. Par exemple, des outils BDD existent pour Java, JavaScript, Ruby, PHP, Python ou l'environnement .NET. L'objectif du BDD est de simplifier la collaboration entre les développeurs et le management grâce à un langage universel, automatisant ainsi la migration du produit dans différents environnements et tests.

Informations générales

Les différences centrales entre le TDD et le BDD sont visibles dans l'approche des logiciels de modélisation et des applications web. Alors que le TDD définit les cas de test avant que le logiciel ne soit créé pour tester ensuite automatiquement les fonctionnalités, le BDD décrit le comportement souhaité du logiciel du point de vue d'un utilisateur, similaire aux user stories dans une programmation extrême. Ces exigences sont formulées dans un langage qui facilite l'intégration des tâches, des objectifs et des résultats d'un logiciel dans différents cadres et systèmes et guide la méthodologie générale de la conception de logiciels.

La langue est destinée à simplifier la mise en œuvre du comportement souhaité d'un logiciel au moyen de certains langages de programmation, afin que tous les développeurs impliqués ainsi que l’équipe de management puissent collaborer. Étant donné que la définition des cas de test peut être complexe et difficile pour les novices dans le cadre du développement axé sur les tests, la langue et l'approche axée sur le domaine avec BDD fonctionnent comme un lien entre les équipes concernées et l'infrastructure utilisée. Au centre du BDD se trouvent le vocabulaire, le cadre, la méthodologie et l'objectif que le logiciel doit accomplir en ce qui concerne les user stories.

Comment ça marche

Le BDD se caractérise par deux fonctions principales :

• Comportement : Le développement du logiciel repose sur le comportement que le produit doit montrer. Cependant, un cas de test n'est disponible que pour le développeur. Il définit les exigences techniques d'un logiciel de telle manière que le personnel formé à la technologie puisse le comprendre. Mais les entrepreneurs, les sponsors et les utilisateurs du logiciel ne seront que partiellement capables d’y contribuer. En mettant l'accent sur le comportement du logiciel, l’harmonisation des problèmes liés à une mise en œuvre techniquement complexe des cas de test produit un certain nombre d’exigences, ainsi que la migration vers d'autres systèmes (développement, test et environnement de production). Les cas d’essai, les exigences et les problèmes spécifiques au domaine sont généralement considérés comme le comportement du logiciel. Au lieu de définir les méthodes d'essai, le comportement du logiciel est décrit, de sorte que tous les participants peuvent comprendre immédiatement la signification et le but des cas de test individuels et des user stories. L'accent sur le comportement du logiciel profite également à la valeur commerciale que peut représenter un logiciel pour une entreprise ou un groupe de clients. Si le logiciel ou l'application web fait exactement ce qu'il est censé faire, les objectifs commerciaux sont au moins partiellement atteints. De plus, l'approche BDD facilite la création de la documentation, des spécifications et des API.
• Langage : L'accent mis sur le comportement conduit directement aux fonctionnalités de contenu du BDD. Un développeur sait ce que le logiciel est censé faire et le conserve dans les catalogues d'exigences. Cependant, le développeur a un accès privilégié à celui-ci, tandis que d'autres participants au projet, tels que la gestion de projet et l'assurance qualité, en sont dispensés. Le langage utilisé avec BDD remédie à cela. Une documentation technique des cas de test est traduite directement en éléments de langue naturelle, de sorte qu'il est également clair à quelles exigences le logiciel doit répondre selon les contextes professionnels complexes du domaine dans lesquels le produit est créé. Grâce au langage universel, le travail sur le logiciel peut être compris dans le moindre détail par tous les participants au projet. L'architecture du logiciel (principalement l'architecture des couches) est directement liée au domaine pour lequel le logiciel est créé. La conception axée sur le domaine est indépendante de certains paradigmes, outils et cadres de programmation, mais est généralement utilisée dans le cadre de la programmation axée sur l’objet.

Exemples

Un exemple typique de la conception axée sur le comportement est la formulation d'un scénario en langue normale, qui est directement orienté vers la logique du logiciel. Les scénarios sont déterminés à l'aide d'expressions logiques standard telles que, si, et, ou, ainsi que toutes les conditions données. Chaque scénario représente une user story abstraite rendue possible par l'application, comme une connexion, l'achat d'un produit sur une boutique en ligne ou la gestion des données de produits commandés. La caractéristique spéciale du BDD est le fait que ces stories sont traduites directement en tests exécutables via un langage universel.

Voici un exemple de processus de connexion sur un site web :

• Données : un compte existant avec des informations clients telles que le nom d'utilisateur, l’adresse e-mail et le mot de passe.
• Le client se connecte à son compte avec ses données d'accès. S'il entre son nom d'utilisateur et son mot de passe sur le site de connexion, son inscription devrait être reconnue et confirmée. En cas de succès, une page de confirmation s'affiche.
• Si les entrées ne sont pas correctes, un message d'erreur s’affiche et indique ce qui a été saisi de manière incorrecte.
• Diverses éventualités, telles qu'une déconnexion au niveau du serveur ou de l'utilisateur, doivent être liées à des conditions disjonctives. Si la communication entre le serveur ou le client échoue, un message d'erreur doit être affiché.

Selon les outils BDD et les cadres utilisés, ces phrases linguistiques sont traduites en code exécutable. Pour cela, elles sont habituellement disposés en lignes de 1 à X et utilisent le vocabulaire, ce qui permet la transition de l’user story vers la logique technique du programme. Dans le même temps, les cas de test sont adéquatement spécifiés avec le vocabulaire, ce qui simplifie considérablement le test automatisé ultérieur des fonctionnalités des applications.

Quelques exemples d’outils BDD :

• Gherkin
• JBehave
• Cucumber
• Behat

Importance pour la programmation

Dan North a conçu le BDD en réponse à la complexité de la conception axée sur les tests. Sa motivation personnelle entrait en jeu, car il a composé plus étroitement avec ce sujet important dans le cadre des méthodes agiles. D'autre part, il voulait faciliter l'accès aux avantages de l'approche test-first pour les débutants dans les méthodes agiles. Dans le contexte de différents environnements de développement, le TDD a conduit à des malentendus et des conflits si les tests n'étaient pas réalisés de manière exhaustive et correcte. Le langage omniprésent utilisé avec le BDD et l'accent sur le comportement de l'utilisateur, et donc l'application, est censé minimiser ces malentendus et difficultés.

Dans le même temps, la gestion de projet, l'assurance qualité et les ingénieurs qui ont mis en place l'infrastructure pour le développement reçoivent une assistance importante qui leur permet de pouvoir prendre les bonnes décisions. Comme pour d'autres approches agiles, les flux de travail, qui nécessitent une coopération harmonieuse des participants au projet, sont au centre de la conception. Le comportement de l'application définit méthodiquement le processus de conception. Le langage universel traduit ce comportement en éléments qui anticipent une analyse du code ainsi que des tests d'acceptation subséquents avant que le logiciel ne soit terminé. L'automatisation des tests permet également de réduire les coûts globaux.

Lien web

• Bonnes pratiques pour la création d'applications base de données, remi-gouyon.developpez.com