Cinq personnes en réunion dans un bureau face à un écran partagé

Ma découverte du Behavior Driven Development (BDD)

Jacqueline Rwanyindo 16 oct. 2023

Constamment désireuse d’améliorer mon travail de développeuse, je découvre des concepts crafts tels que le Behavior Driven Development (BDD), les 3 amigos et l’Acceptance Test Driven Development (ATDD) grâce à ma veille. Leur bénéfice ? Optimiser la coopération avec le métier. Fascinée, je me demande comment passer de la théorie à la pratique.

Quelque temps plus tard, me voilà dans une agence qui prône ces méthodologies. Dès ma première semaine, je participe à une formation sur le BDD et j’intègre une mission influencée par le Software Craftsmanship. Depuis, une année s’est écoulée. Aujourd’hui, je vous propose un petit retour d’expérience autour de ma découverte de ces concepts sur le terrain.

Séances de BDD avec les 3 amigos

Un besoin a été remonté et priorisé. Une ou des séances de BDD sont organisées. Notre Product Owner, qui a analysé en amont le besoin, anime ces séances en nous présentant les enjeux métier de la fonctionnalité. Chaque membre de l’équipe est amené·e à participer à la discussion, demander des explications, proposer des solutions… Nous sommes les 3 amigos.

Les 3 amigos représentent trois points de vue, à savoir le métier, la technique et l’assurance qualité. Nous nous sommes engagé·e·s à ne pas limiter la conversation à trois personnes. Chaque membre de l’équipe projet pouvant contribuer à l’étude du besoin et à sa réalisation est présent·e et s’implique. Dans notre cas, cette équipe est composée du Product Owner, du garant de la donnée, des développeurs et développeuses au complet.

Nous imaginons tous les cas de figures envisageables en les illustrant par des exemples concrets. Chaque phrase, chaque mot, chaque verbe peut faire l’objet d’un débat. Nous veillons à faire ressortir toutes les problématiques de la fonctionnalité. L’Ubiquitous Language, vocabulaire qui permet à toutes les parties prenantes de parler le même langage, émerge. Petit conseil : attention à ne pas se perdre dans des digressions lors des débats. Cela nous a parfois fait défaut.

Le but est qu’à l’issue des séances tout le monde partage la même compréhension du besoin métier. Un ou des tickets sont ajoutés à notre outil de gestion de projet. Le contenu est le résultat de ces séances et non pas la réflexion unique du Product Owner sur le sujet. Ainsi, chaque développeur·euse est capable d'implémenter la fonctionnalité en évitant les ambiguïtés et les mésinterprétations.

Il peut arriver qu’aucun scénario ne soit écrit au cours d’une séance. Aucune déception ! Les réflexions engendrées alimentent le socle de connaissances partagées. Elles pourront être utiles pour la prochaine séance, ou la conclusion peut être de reporter la fonctionnalité… Ces séances sans scénario sont rares mais toujours enrichissantes.

Rédaction d’une fonctionnalité

Pendant les séances, un·e scribe est désigné·e. En général, pour une fonctionnalité, nous créons un seul fichier décrivant les spécifications. L'équipe a décidé d’utiliser le format Gherkin pour standardiser nos échanges et poser un cadre à nos réflexions. La première étape consiste à choisir un titre. Quel est le sujet de notre fonctionnalité ? Puis, nous complétons la phrase “En tant que… Je souhaite… Afin de…”, notre User Story. Ce qui nous permet de situer la fonctionnalité par rapport au reste de l’application.

Un fichier Gherkin contient un seul ou plusieurs scénarios qui représentent les différents cas d’exemple qui émergent au cours de nos discussions. Un cas d’exemple contient un titre et des étapes distinguées par les mots clés Étant donné (Given), Quand (When) et Alors (Then). La définition de ces étapes peut être mise en parallèle avec la démarche scientifique.

Étant donné : Observation et hypothèses

En général, un contexte de départ conditionne le bon déroulement de la fonctionnalité. Nous émettons des hypothèses et définissons les prérequis à notre scénario. Quelles informations sont nécessaires à la réalisation du besoin ?

Quand : Expérience

Nous déterminons un déclencheur par lequel des actions manipulent notre application. Nous nous demandons “Quel comportement se produit et à quel moment est-il possible ?”

Alors : Résultat et interprétation

L’attendu est à définir. Quel résultat devons-nous obtenir à l’issue de l’exécution de la fonctionnalité pour nous assurer que son objectif est atteint ?

Nous pouvons très bien commencer l’écriture d’un scénario par l’attendu et ensuite remonter le fil. Quand on connaît la destination, il est plus facile de trouver le chemin.

Nous itérons par l’écriture d’autres scénarios en ajustant le contexte de l’expérience et ainsi valider d’autres hypothèses. Prendre le temps de rédiger tous les cas d’exemple possibles est primordial.

Implémentation en boucle

Une fois que l’écriture des scénarios de la fonctionnalité est terminée et que celle-ci est embarquée dans un sprint, nous pouvons nous lancer dans son implémentation à l’aide du framework BDD Cucumber. Nos scénarios deviennent nos tests d’acceptation.

Notre première tâche consiste à implémenter les étapes Given-When-Then afin de convertir le texte Gherkin via le langage de programmation du projet. Cela nous amène à créer de nouvelles classes propres à la fonctionnalité. Trouver la bonne manière de nommer une classe est parfois délicat. Ici, nous nous basons sur notre Ubiquitous Language, tout simplement. Nous codons juste assez d’éléments pour que notre test compile et soit en échec à son lancement car l’attendu est faux. Puis, nous pouvons nous lancer dans la conception de la solution.

Lorsqu’une fonctionnalité contient plusieurs scénarios, j’ai pris l’habitude de commencer par commenter tous les cas d’exemple sauf un. Une fois que le test d’acceptation échoue pour les bonnes raisons (l’attendu non résolu), je travaille progressivement sur la solution à l’aide de tests unitaires (Test Driven Development). Ma charge mentale est moindre. Je ne me demande pas par quoi commencer. Je suis guidée par les tests ! Quand le premier scénario est passé au vert, je décommente le suivant, implémente les étapes manquantes et rebelote. Nous pouvons parler de double boucle (A)TDD.

Acceptance-Test-Driven-Development-ATDD-schema

Source : Acceptance Test-Driven Development (ATDD)

Isolation du métier

Nos scénarios Gherkin se focalisent sur le métier. Nous évitons tous termes techniques comme “requête HTTP”. Via des contrats, le cœur de notre application (aka le métier, aka le domain) communique avec l’infrastructure qui comprend ces notions plus techniques. Par exemple, le recours à une librairie externe permettant l’envoi d’e-mail ou la sauvegarde en base de données via un framework ORM (Object-Relational Mapping).

Cette séparation claire entre la logique métier et le recours à des solutions tierces nous permet de protéger cette première, la plus-value de notre application. Si une librairie évolue ou doit être remplacée, nos scénarios et leur implémentation ne devraient pas être impactés. De plus, la testabilité des deux parties est facilitée.

J’ai adopté un petit rituel. Une fois que tous les critères d’acceptation sont passés au vert, j’attaque l’implémentation de l’infra. Je commence par l’utilisation de librairies externes consommées par la fonctionnalité (secondary). Puis, le point d’entrée de notre application vers notre fonctionnalité (primary). Si une base de données est sollicitée, ce sera ma toute dernière étape. En attendant, je peux me contenter de classes InMemory en guise de substitut.

Tout cela est possible parce que notre conception logicielle est pilotée par le métier (Domain Driven Design) et l'architecture de notre projet se veut clean ou hexagonale ou clean archigonale...

Hexagone-schema

Source : Spring Boot Java dans l'hexagone

Documentation vivante

Nos scénarios Gherkin nous guident dans la conception de notre fonctionnalité via l’outil Cucumber. L'automatisation de ces tests nous rassure sur la non-régression de notre application. Cerise sur le gâteau : nous obtenons une documentation vivante.

Lorsque j’ai commencé la mission, le projet avait débuté depuis plusieurs mois. Lire les cas d’exemple m’a aidée à appréhender les enjeux de l’application. Quand nous avons un doute sur un choix passé, une relecture peut nous éclairer. De même, pendant nos séances de BDD, nous pouvons nous appuyer sur de précédents scénarios pour nous rafraîchir la mémoire et accompagner notre réflexion.

Réécriture

Nous pouvons être amené·e·s à re-challenger un scénario. Il n’est pas question de considérer nos textes Gherkin comme gravés dans le marbre. Notre compréhension du métier s’affine au fil du temps. Nos scénarios évoluent en conséquence. Ces adaptations doivent toujours être rédigées en concertation et orientées métier. Le BDD est une affaire d’équipe agile.

Conclusion

Mettre en place ces méthodologies n’est pas si évident. Gregory Elhaimer nous met en garde dans son article “4 idées reçues sur le BDD (Behavior Driven Development)”. Un temps d’apprentissage est nécessaire. Une fois l’équipe à l’aise avec l’approche BDD, un cercle vertueux commence : attendu clair pour chaque membre de l’équipe, charge mentale moindre pour les devs lors de l’implémentation, documentation qui évolue au même rythme que le projet, qualité des livrables…

Être exigeant·e et exhaustif·ive dans nos cas d’exemple, pendant les séances de BDD, réduit considérablement les malentendus tout au long de la vie de l’application. Les scénarios peuvent participer à l’onboarding des nouvelles et nouveaux membres de l’équipe. Les apartés volatiles avec les analystes en raison d’interrogations métier pendant l’implémentation sont rares car les questions ont été posées en amont. Les cas d’exemple constituent notre roadmap. Gain de temps et efficacité sont assurés !

Depuis sa mise en production, l’application démontre stabilité et performance. À ce jour, aucun bug fonctionnel n’a été remonté. Les fonctionnalités se comportent comme spécifiées. Les KPI tels que l’utilisabilité (clarté de l’outil, connaissances pré-requises…) dépassent les 80%. Ce qui est un très bon chiffre comparé au score obtenu par la solution logicielle précédente avec une progression de plus de 40%. Bien que l’ancien outil soit toujours disponible, l’adoption de la nouvelle application est totale.

Je pense que la mise en œuvre de pratiques qui mettent en exergue le métier (BDD, DDD, ATDD…) a largement contribué à ce succès. Elle a assurément participé à la cohésion de l’équipe ainsi qu’à un sentiment de sérénité en ce qui doit être produit et ce qui est livré.

Au cours de cette année, j’ai découvert que la rumeur est vraie. Le craft, c’est trop bien.