Tests BDD : le développement piloté par le comportement expliqué

Les tests BDD (behavior-driven development, ou développement piloté par le comportement) consistent à rédiger des scénarios de test dans un langage clair et structuré, au format Given/When/Then, pour que les développeurs, les ingénieurs QA et les responsables métier puissent lire la même spécification et s’accorder dessus avant la mise en production d’une fonctionnalité. Des outils comme Cucumber exécutent ensuite ces scénarios sous forme de tests automatisés sur le produit réel.

Savoir si votre équipe a besoin de tests BDD se résume à une question : une personne qui n’a jamais écrit de code doit-elle pouvoir lire vos tests ? Avec le BDD, un product manager peut lire « Étant donné un utilisateur connecté, Quand il ajoute un article au panier, Alors le total du panier est mis à jour », savoir exactement ce qui est vérifié et repérer ce qui manque. Cette lisibilité a un coût. Chaque ligne en langage courant a besoin de code derrière elle, et quelqu’un doit garder les deux synchronisés à mesure que le produit évolue.

Le BDD est désormais une pratique courante dans les équipes de test. Dans l’enquête State of Testing 2024 de PractiTest et Tea-time with Testers, l’adoption du BDD est passée de 19 % des répondants en 2022 à 26 % en 2024, légèrement devant le développement piloté par les tests (TDD) à 23 %, et 92 % des répondants travaillaient selon des modèles Agile ou proches de l’Agile.

Ce guide explique la structure Given/When/Then, comment les outils BDD s’intègrent aux tests automatisés, ce qui distingue le BDD du TDD et dans quels cas l’effort supplémentaire est rentable.

La structure Given/When/Then en BDD

Chaque scénario BDD suit la même structure en trois parties :

• Given (Étant donné) fixe l’état de départ : qui est l’utilisateur, quelles données existent, sur quel écran il se trouve.
• When (Quand) décrit l’action ou l’événement unique testé.
• Then (Alors) énonce le résultat attendu qui compte pour le métier.

And (Et) et But (Mais) prolongent n’importe laquelle des trois quand une étape demande plus d’une ligne. Cette syntaxe s’appelle Gherkin et se trouve dans des fichiers texte .feature que tout le monde dans l’équipe peut ouvrir. La référence Gherkin liste l’ensemble des mots-clés, traduits dans plus de 70 langues : avec la ligne # language: fr en tête de fichier, votre équipe rédige ses scénarios en français.

Voici l’exemple du panier écrit comme un vrai scénario :

# language: fr
Fonctionnalité: Panier

  Scénario: Ajouter un article met à jour le total du panier
    Étant donné un utilisateur connecté avec un panier vide
    Quand il ajoute un carnet à 25 € au panier
    Alors le panier affiche 1 article
    Et le total du panier est de 25,00 €

Un product owner peut confirmer qu’il s’agit bien du comportement voulu, un développeur peut s’en servir pour construire, et un ingénieur QA peut l’automatiser, le tout à partir du même texte.

Tout l’art consiste à décrire des comportements plutôt que des clics. « Quand il clique sur le bouton avec l’id add-to-cart » lie le scénario à l’interface actuelle et casse à la prochaine refonte. « Quand il ajoute un carnet à 25 € au panier » survit à une refonte et se lit toujours comme une règle métier. Les Scenario Outlines (plans du scénario) vont plus loin : un scénario et un tableau de valeurs d’exemple couvrent dix codes de réduction ou cinq rôles utilisateur sans dix copies des mêmes étapes.

Cette source de vérité unique et lisible cible une faiblesse fréquente. La même enquête State of Testing 2024 a montré que dans 60 % des organisations, les cas de test ne sont pas bien rédigés ni maintenus, la duplication et le manque de maintenance en étant les causes habituelles.

Comment fonctionnent réellement les outils de tests BDD

Les outils BDD se placent au-dessus de votre framework d’automatisation des tests et lui confient le vrai travail. Les scénarios décrivent ce que le produit doit faire, et le framework sous-jacent exécute chaque étape dans le navigateur, l’application mobile ou l’API. Les équipes qui disposent déjà d’une suite automatisée peuvent généralement ajouter une couche BDD progressivement, un parcours métier à la fois, en conservant les tests existants. Une configuration BDD comporte trois couches :

Cucumber est l’outil BDD le plus utilisé, avec des implémentations pour Java, JavaScript, Ruby et d’autres langages. Behave couvre Python, Reqnroll (le successeur de SpecFlow) couvre .NET, et CodeceptJS prend en charge les scénarios Gherkin pour les équipes JavaScript. Pour les tests d’API, Karate utilise directement une syntaxe de type Gherkin, l’une des raisons pour lesquelles il revient souvent quand les équipes comparent Karate et REST-Assured.

Quand Cucumber exécute Quand il ajoute un carnet à 25 € au panier, il trouve la définition d’étape correspondante, qui appelle à son tour Playwright ou Selenium pour réaliser l’action. Cette organisation en couches a deux conséquences pratiques :

• Le BDD hérite de la qualité du framework sous-jacent. Des localisateurs instables ou des environnements de test lents restent instables et lents derrière un scénario lisible.
• Les non-développeurs peuvent contribuer à la conception des tests. Dans l’enquête de 2024, 42 % des répondants déclaraient ne pas se sentir à l’aise pour écrire des scripts d’automatisation. Les scénarios en langage courant permettent à ces testeurs, et aux équipes produit, de définir ce qui est automatisé, tandis que les ingénieurs prennent en charge le code des étapes.

Les scénarios BDD servent d’interface lisible aux tests fonctionnels automatisés : ils vérifient de bout en bout que les fonctionnalités se comportent comme le métier l’attend.

BDD vs TDD : quelle différence ?

Le BDD est né du développement piloté par les tests (TDD) au milieu des années 2000, lorsque Dan North a commencé à décrire les tests comme des comportements pour rendre le TDD plus facile à enseigner et à discuter. Aujourd’hui, les deux répondent à des problèmes différents.

En développement piloté par les tests, un développeur écrit un petit test unitaire qui échoue, écrit juste assez de code pour le faire passer, puis refactorise. Les tests vivent dans le code et s’adressent à d’autres développeurs. Le BDD élève la conversation d’un niveau, vers un comportement qu’un client ou un responsable métier reconnaîtrait.

Beaucoup d’équipes utilisent les deux : le TDD pour la logique interne, le BDD pour les quelques parcours métier que les parties prenantes doivent valider. La progression régulière des deux pratiques montre que l’approche « all team testing » gagne du terrain, avec des développeurs, des QA et des équipes produit qui partagent la responsabilité de la qualité au sein des équipes R&D.

Quand les tests BDD valent l’effort

Le BDD ajoute un vrai travail en plus de l’automatisation. Quelqu’un doit animer de courtes séances de scénarios avec le produit, le développement et la QA (souvent appelées réunions des « three amigos »), entretenir un vocabulaire d’étapes partagé pour que les scénarios ne dérivent pas en quasi-doublons, et maintenir les définitions d’étapes à mesure que l’interface change. Si personne en dehors de l’équipe technique ne lit les scénarios, ce travail ne rapporte rien.

Le BDD est généralement rentable quand :

• Les règles métier sont complexes ou sujettes à débat. La tarification, l’éligibilité, les droits d’accès et la logique de remboursement sont la source des bugs du type « ce n’est pas ce qu’on voulait dire ».
• Des personnes non techniques valident le comportement. Les product owners, les responsables conformité ou l’équipe de recette d’un client peuvent relire directement les scénarios.
• Les ingénieurs QA manuels doivent contribuer à l’automatisation sans devenir développeurs à plein temps.
• Vous avez besoin d’une documentation vivante. Les scénarios exécutés en CI/CD montrent ce que fait le produit aujourd’hui, ce qui aide pour l’intégration des nouveaux arrivants et les audits.

C’est généralement un mauvais choix quand :

• La suite est réservée aux développeurs : tests unitaires, bibliothèques internes, code d’infrastructure.
• Le produit est un prototype qui évolue vite et dont le comportement change chaque semaine.
• Il n’existe pas encore de base d’automatisation stable. Consolidez d’abord le framework, puis ajoutez la couche lisible.

Au fond, l’argument porte sur la communication. Dans l’enquête PractiTest de 2025, les compétences en communication sont passées de 59 % en 2024 à 75 % en 2025, devenant la première compétence dont les testeurs disent avoir besoin, ce que les auteurs attribuent au travail étroit des testeurs avec des équipes Agile et DevOps transverses. Le BDD transforme cette collaboration en un livrable concret, et un malentendu repéré lors de la relecture d’un scénario coûte bien moins cher qu’un malentendu découvert en production. Cette courbe des coûts explique aussi l’importance de l’assurance qualité dès le début du développement.

Comment QAwerk utilise le BDD sur un projet réel

Sur Evolv, une plateforme d’optimisation de la croissance digitale pilotée par l’IA, l’équipe du client utilisait déjà CucumberStudio comme outil de collaboration BDD pour ses cas de test manuels. L’automatisation de QAwerk reposait sur CodeceptJS avec Puppeteer. Plutôt que d’imposer un outil à la place de l’autre, nos ingénieurs ont créé un petit générateur qui produit le code de liaison entre CucumberStudio et le projet CodeceptJS dans les deux sens, avec des scénarios exécutés dans le pipeline CI/CD.

Résultat, l’automatisation est devenue accessible à toute l’équipe QA :

• Les ingénieurs QA manuels construisent de nouveaux scénarios à partir d’une bibliothèque de plus de 100 Action Words, avec une prise en main minimale.
• Quand un localisateur ou l’ordre des étapes change, ils le corrigent en modifiant les étapes dans CucumberStudio au lieu de pousser des modifications de code.
• Les étapes de bas niveau sont progressivement refactorisées en phrases Gherkin de niveau métier que l’équipe d’Evolv peut lire.

Cela a fonctionné parce que les deux équipes ont travaillé comme une seule. L’équipe d’Evolv préparait la documentation de débogage pendant que nous rédigions les cas de test, et nous sommes intervenus à chaque étape où se trouvait la plateforme, de l’ancienne application web au nouveau produit. Si vous ne savez pas si le BDD convient à votre projet, dites-nous ce que vous développez et nous vous répondrons franchement.

Les tests BDD sont-ils adaptés à votre équipe ?

Le BDD justifie son effort lorsqu’il comble un vrai fossé de communication entre ceux qui construisent le logiciel et ceux qui décident de ce qu’il doit faire. Il résout un problème différent de celui du TDD, et de nombreuses équipes solides utilisent l’un, l’autre ou les deux.

Les ingénieurs en automatisation de QAwerk peuvent ajouter Cucumber ou un autre outil BDD au-dessus du framework qui convient déjà à votre stack, pour que vous obteniez des scénarios lisibles sans reconstruire votre suite de tests. Si vous préférez une équipe de test dédiée qui rédige les scénarios avec vos product owners et les fait tourner en CI, c’est ainsi que nous commençons en général.

Questions fréquentes

Découvrez comment nous avons testé une solution de croissance digitale basée sur l’IA et augmenté de 50 % la vitesse des tests de régression

Veuillez saisir votre adresse courriel professionnelle n'est pas un courriel professionnel

Obtenir l’étude de cas