Développement piloté par le comportement, comment utiliser la méthode BDD ?

Dans un processus de développement de logiciel traditionnel, les développeurs écrivent des programmes et créent des fonctionnalités, et les testeurs testent ensuite les logiciels écrits. Cependant, les entreprises fonctionnent désormais à un rythme plus rapide et, par conséquent, le développement de logiciels doit suivre les demandes métiers.

Il est ainsi possible aujourd’hui d’assurer une plus grande qualité des logiciels. À ce rythme de développement, le processus de développement logiciel traditionnel s’est déplacé vers des méthodologies plus Agiles. L’un d’entre eux est le développement piloté par le comportement (BDD).

Qu’est-ce que le développement piloté par le comportement (BDD) ?

Le développement piloté par le comportement (BDD) est une méthodologie de développement logiciel Agile dans laquelle une application est documentée et conçue autour du comportement qu’un utilisateur s’attend à rencontrer lorsqu’il interagit avec elle.

Cette méthode de développement aide les développeurs à se concentrer uniquement sur le comportement demandé d’une application ou d’un programme. Son principal objectif est d’éviter l’abus de code, les fonctionnalités inutiles et le manque de concentration. Cette méthodologie combine, augmente et affine les pratiques utilisées dans le développement piloté par les tests (TDD) et les tests d’acceptation.

Un projet typique utilisant le développement piloté par le comportement commencerait par une conversation entre les développeurs, les managers et le client pour former une vision globale de la façon dont un produit est censé fonctionner. La méthode entre ensuite en scène après avoir effectué tous les tests utilisateurs nécessaires. Les attentes concernant le comportement du produit sont alors définies comme objectifs pour les développeurs, et une fois que tous les tests de comportement ont réussi, le produit a satisfait à ses exigences et est prêt à être livré au client.

Le BDD offre la possibilité d’élargir le pool d’entrées et de commentaires pour inclure les parties prenantes de l’entreprise et les utilisateurs finaux qui peuvent avoir peu de connaissances en développement logiciel. Les équipes de développement peuvent utiliser plus facilement BDD dans des environnements d’intégration continue et de livraison continue. De plus, il est parfaitement possible de combiner l’usage de cette méthodologie agile à celui d’un test utilisateur, comme le TDD, pour avoir un résultat plus affiné.

Développement piloté par le comportement et automatisation des tests

La méthode BDD nous oblige à repenser notre approche des tests unitaires et des tests d’acceptation afin d’éviter les problèmes qui surviennent naturellement dans le développement d’une application.

Les tests unitaires doivent être spécifiés en termes de comportement souhaité, c’est-à-dire les exigences définies par le métier. En spécifiant ces termes à l’avance, nous nous assurons que les développeurs n’auront pas à revoir leur développement parce que les exigences ont été mal comprises. En d’autres mots, nous assurons un développement rapide, fiable et pertinent.

Dans le développement piloté par le comportement, nous créons des scénarios respectant les valeurs exigées par le métier. Les noms des tests unitaires sont des phrases entières écrites par ordre de valeur métier. Au tout début d’un fichier de fonctionnalité, nous écrivons des tests d’acceptation en utilisant le cadre agile standard d’une user story :

• En tant que (rôle)
• Je veux (fonctionnalité)
• Alors que (bénéfice)

Une fois que le fichier de fonctionnalités a été établi (feature) et accepté par les participants du projet, nous écrivons ensuite les critères d’acceptation pour tester ce comportement. Les critères d’acceptation d’une fonctionnalité sont écrits en termes de scénarios et implémentés sous forme de classes. Cela permet de mapper les étapes d’un fichier de fonctionnalités à des actions concrètes.

Il faudra alors écrire un scénario au format suivant :

• Étant donné que (contexte initial)
• Quand (l’événement se produit)
• Alors (résultat attendu)
• Et/Mais (plus de résultats le cas échéant)

Le BBD permet une automatisation facile des tests. La suite de tests unitaires fournit en permanence des commentaires pour s’assurer que chaque composant clé fonctionne toujours. Les tests unitaires agissent comme une documentation permanente.

Conclusion

Le développement piloté par le comportement ou BDD est une forme d’automatisation test offrant un certain avantage. En l’utilisant, les entreprises peuvent rationaliser les activités de développement de logiciels ou applications.

Le BDD est une méthode de travail qui s’applique à la fois au développement, en utilisant les tests unitaires, et également à l’assurance qualité avec les tests automatisés.

Lorsque nous aurons besoin de maintenir ou faire évoluer le système, les tests automatisés nous aideront à comprendre ce que le système fait actuellement et à apporter des modifications en toute sécurité sans rien « casser » involontairement.

Ceci réduit le « fardeau » des tests de régression manuels, libérant les parties concernées pour réaliser un travail plus intéressant, comme les tests exploratoires.