BDD en JavaScript : écrire des tests que le métier comprend

Comment expliquer à un développeur qu'un bug n'est pas « ça ne marche pas » ?

Avez-vous déjà reçu une tâche du style : « Fais en sorte que le bouton fonctionne correctement » ? Ou, pire encore, avez-vous écrit du code, les tests sont verts, mais le client dit : « Eh bien, ce n'est pas ce que j'ai demandé ». Une douleur familière ? Bienvenue dans le monde où le BDD (Behaviour-Driven Development) en JavaScript devient une bouée de sauvetage.

Le BDD n'est pas simplement un autre acronyme à la mode. C'est une approche qui force les développeurs, les testeurs et les analystes métier à parler le même langage. Un langage vivant, sans « méthodologies » ni « paradigmes architecturaux ». Aujourd'hui, nous allons voir comment intégrer le BDD dans un projet JavaScript, écrire de vrais tests et comprendre pourquoi cela rend le code plus propre et la vie plus simple.

Qu'est-ce que le BDD et en quoi diffère-t-il du TDD ?

Mettons les choses au clair tout de suite. Le BDD (Behaviour-Driven Development) est une évolution du TDD (Test-Driven Development). Si le TDD dit : « D'abord écris le test, ensuite le code », le BDD ajoute : « Mais le test doit être compréhensible pour une grand-mère investisseuse ».

L'idée clé du BDD : nous testons le comportement du système, pas son fonctionnement interne. Nous ne demandons pas : « La fonction retourne-t-elle true ? ». Nous demandons : « L'utilisateur peut-il ajouter un produit au panier et voir le montant de la commande ? ». La différence est colossale.

Pour le BDD en JavaScript, il existe un langage spécial — le Gherkin. C'est un pseudo-anglais (ou pseudo-français) qui ressemble à une notice de construction Lego :

Fonctionnalité : Panier d'achats\n  En tant qu'utilisateur enregistré\n  Je veux ajouter des articles au panier\n  Afin de voir le coût total\n\n  Scénario : Ajout d'un article\n    Étant donné que l'utilisateur est connecté\n    Quand il ajoute l'article "Ordinateur portable" au panier\n    Alors le panier affiche 1 article\n    Et le coût total est de 99900 roubles\n

Vous en conviendrez, cela se lit comme une exigence métier, pas comme du code. Et c'est là le principal atout du BDD.

Outils pour le BDD en JavaScript

Pour pratiquer le développement piloté par le comportement en JavaScript, il faut les bons outils. Voici les trois piliers sur lesquels tout repose :

\n
• Cucumber.js — le framework BDD le plus populaire. Il analyse les scénarios Gherkin et les relie au code.
\n
• Jest + Jest-Cucumber — si vous utilisez déjà Jest, c'est l'option idéale. Aucune magie, juste une intégration propre.
\n
• Mocha + Chai + Gherkin — pour ceux qui aiment assembler les pièces manuellement. Flexible, mais plus de code.
\n

Nous allons utiliser Cucumber.js, car c'est le standard de l'industrie. L'installation est simple :

npm install @cucumber/cucumber --save-dev\n

Ensuite, créez un dossier features/ — c'est là que vivront nos fichiers .feature. Et dans le dossier step_definitions/ — le code qui donne vie aux scénarios.

Écrire notre premier test BDD : authentification utilisateur

Imaginons que nous créons une boutique en ligne. La première chose à tester est la connexion. Créons le fichier features/login.feature :

# language: fr\nFonctionnalité : Authentification utilisateur\n  En tant que visiteur du site\n  Je veux me connecter à mon espace personnel\n  Afin de gérer mes commandes\n\n  Scénario : Connexion réussie avec des identifiants corrects\n    Étant donné que je suis sur la page de connexion\n    Quand je saisis l'email "user@example.com" et le mot de passe "123456"\n    Et que je clique sur le bouton "Connexion"\n    Alors je vois le message de bienvenue "Bienvenue, Ivan !"\n

Maintenant, il faut écrire les étapes (steps) — le code JavaScript qui exécutera ces actions. Créons step_definitions/login.steps.js :

const { Given, When, Then } = require('@cucumber/cucumber');\nconst { expect } = require('chai');\n\n// État de l'application (simulation)\nlet currentPage = '';\nlet userEmail =