BDD (Behavior-Driven Development)

Le Behavior-Driven Development (BDD, développement piloté par le comportement) est une manière de construire une compréhension commune avant d’écrire le code. Produit, développement et test (souvent appelés les « three amigos ») discutent d’une fonctionnalité à travers des exemples concrets de la façon dont elle doit se comporter. Ces exemples deviennent les critères d’acceptation, et beaucoup d’équipes les automatisent ensuite sous forme de spécifications exécutables avec des outils comme Cucumber, Reqnroll (le successeur de SpecFlow) ou Behave.

Exemple

Une discussion sur une règle de remise se transforme en exemples comme ceux-ci :

Feature: Loyalty discount

  Scenario: Gold members get 10% off orders over 100
    Given a customer with Gold membership
    When they check out a basket worth 120.00
    Then the order total is 108.00

  Scenario: The discount does not apply at exactly 100
    Given a customer with Gold membership
    When they check out a basket worth 100.00
    Then the order total is 100.00

C’est le second scénario qui a de la valeur. Le rédiger oblige à poser la question « au-delà de 100, ou à partir de 100 ? » avant que quiconque ne développe la mauvaise chose.

Les trois pratiques

1. Découverte (Discovery). Explorer la fonctionnalité avec des exemples, trouver les cas limites et les questions ouvertes.
2. Formulation. Écrire les exemples convenus sous une forme structurée et lisible par le métier, généralement en Gherkin.
3. Automatisation. Relier chaque étape à du code pour que les exemples s’exécutent comme des tests et servent de documentation vivante.

Erreurs courantes

• Considérer le BDD comme un outil de test. Écrire du Gherkin après le code, seul, sans aucune discussion, vous donne le coût d’une couche de traduction sans le bénéfice d’une compréhension partagée.
• Des étapes au niveau de l’UI. « When I click the button with id submit » décrit l’interface, pas le comportement. Les étapes doivent survivre à une refonte.
• Automatiser chaque scénario via le navigateur. Une règle métier comme la remise ci-dessus est généralement plus rapide et plus fiable à automatiser au niveau de l’API ou de la couche service.
• D’énormes bibliothèques d’étapes. Des centaines de step definitions légèrement différentes sont difficiles à maintenir. Gardez un vocabulaire restreint et centré sur le domaine.

Le BDD fonctionne bien quand les personnes du métier lisent réellement les scénarios et y contribuent. Quand personne en dehors de l’équipe technique ne les regarde, du code de test classique avec de bons noms est souvent plus simple.