Questions d'entretien BDD et Cucumber

Le BDD, c'est décrire comment une fonctionnalité doit se comporter dans un langage clair et structuré sur lequel tout le monde s'accorde — avant qu'elle soit construite — pour que la même description guide la conversation, le code et les tests.

Ce que les gens ratent : le BDD est d'abord une pratique de collaboration, un outil ensuite. Cucumber et Gherkin sont la façon de l'écrire, mais la valeur est la compréhension partagée entre le produit, le dev et la QA — pas les fichiers .feature eux-mêmes.

Le TDD est une discipline de développeur — écrire un test unitaire qui échoue, le faire passer, refactoriser. Il porte sur la justesse du code, dans le langage du développeur. Le BDD est un pas de côté : il décrit le comportement du point de vue de l'utilisateur, dans un langage que toute l'équipe partage, et guide généralement des tests de plus haut niveau.

Ce ne sont pas des rivaux — beaucoup d'équipes font les deux : les scénarios BDD cadrent quoi construire, le TDD guide les unités en dessous. Le BDD répond à « construit-on la bonne chose ? » ; le TDD répond à « construit-on la chose correctement ? »

Gherkin est la syntaxe en langage clair que Cucumber lit. Un scénario a trois temps : Given pose l'état de départ, When est l'action testée, Then est le résultat attendu.

La discipline, c'est une action par scénario. Given je suis connecté en tant qu'admin, When je supprime un utilisateur, Then l'utilisateur n'apparaît plus. Gardez Given pour le contexte, When pour le seul déclencheur, et Then pour les résultats observables — pas un état interne que personne ne peut voir.

Un bon scénario se lit comme une règle métier : un comportement, déclaratif, sans mécanique d'UI. « When le client applique un coupon expiré, Then il voit une erreur » — il survit à une refonte parce qu'il dit quoi, pas comment.

Un mauvais scénario est un script de clics : « When je clique sur #coupon-field, And je tape SAVE10, And je clique sur le bouton… ». C'est impératif, fragile, et ça ne dit rien à un lecteur métier. Si votre Gherkin mentionne des sélecteurs CSS ou des ID de boutons, il a cessé d'être du BDD.

Un Scenario est un cas concret unique. Un Scenario Outline est un modèle exécuté une fois par ligne d'une table Examples — mêmes étapes, données différentes, avec des <espaces réservés>.

Vous prenez un outline quand le même comportement doit être vérifié sur plusieurs entrées : e-mails valides et invalides, montants limites, rôles différents. Un outline avec cinq lignes Examples bat cinq scénarios copiés-collés — et il rend visibles en une table les données que vous couvrez.

Les définitions d'étapes sont le code derrière chaque ligne Gherkin. Cucumber fait correspondre le texte d'une étape à une définition par un motif (regex ou expression Cucumber), capture les paramètres, et exécute cette méthode.

Ainsi « When j'applique le coupon SAVE10 » correspond à une fonction qui prend « SAVE10 » et fait le vrai travail — cliquer, appeler l'API, peu importe. Le Gherkin reste clair ; la mécanique vit ici. Une définition bien paramétrée peut servir de nombreux scénarios.

Background contient les étapes Given que chaque scénario d'un fichier feature partage — il s'exécute avant chacun, donc vous écrivez la mise en place commune une seule fois au lieu de la répéter.

Ne le surchargez pas. Si le Background dépasse quelques lignes, ou si les scénarios n'en utilisent que la moitié, il cesse d'aider et cache le contexte — un lecteur doit remonter pour comprendre un seul scénario. Gardez-le pour une mise en place vraiment universelle ; tout ce qui est spécifique appartient au scénario.

Les tags sont des étiquettes comme @smoke ou @regression au-dessus des scénarios. À l'exécution vous filtrez par eux — ne lancer que @smoke à chaque push, le @regression complet la nuit. Ils pilotent aussi des hooks tagués : un hook @db qui amorce des données uniquement pour les scénarios qui en ont besoin.

C'est ainsi qu'une suite sert plusieurs objectifs sans dupliquer les scénarios. La discipline, c'est un petit vocabulaire de tags convenu — @wip, @smoke, @slow — pas une prolifération que personne ne retient.

Les hooks sont des blocs qui s'exécutent autour des scénarios — Before, After, et leurs variantes taguées. Ils contiennent la mise en place et le nettoyage techniques que vous ne voulez pas encombrer le Gherkin : ouvrir le navigateur, amorcer des données, prendre une capture d'écran en cas d'échec, fermer les connexions.

La règle, c'est que les hooks sont pour la plomberie, pas le comportement. Tout ce qu'un lecteur métier devrait voir — l'état dans lequel un scénario démarre — appartient à un Given ou un Background. Si un hook fait quelque chose dont le sens du scénario dépend, il cache le test.

Les trois, ensemble — ce sont les « trois amigos » : une voix métier/produit, un développeur, et un testeur, avant que le travail commence. Le produit apporte l'intention, le développeur signale ce qui est techniquement difficile, le testeur fait remonter les cas limites et les chemins d'erreur que personne n'a mentionnés.

Quand une seule personne écrit les scénarios seule, vous perdez tout le bénéfice — la QA les écrivant seule produit juste des tests en Gherkin, et le produit les écrivant seul rate les cas limites. La conversation est le livrable ; le fichier .feature est le compte rendu.

Les scénarios impératifs détaillent chaque étape mécanique — cliquer ceci, taper cela, presser le bouton. Les scénarios déclaratifs énoncent l'intention — « When le client paie avec une carte expirée » — et laissent les définitions d'étapes gérer le comment.

Le déclaratif l'emporte presque toujours : il se lit comme une règle métier, survit aux refontes d'UI, et reste court. Le Gherkin impératif est fragile et illisible pour les gens non techniques que le BDD existe pour inclure. La compétence est de pousser le détail dans les étapes et de garder le fichier .feature au niveau du comportement.

Quand vous gardez l'outillage et lâchez la collaboration. Les équipes adoptent Cucumber, sautent la conversation des trois amigos, et finissent par écrire des tests en Gherkin après coup — maintenant chaque test porte la lourdeur d'un fichier feature, d'une définition d'étape et d'un appariement de motifs, sans aucun gain de compréhension partagée.

Ça échoue aussi quand les scénarios deviennent impératifs (des scripts de clics fragiles), quand la bibliothèque d'étapes prolifère sans entretien, ou quand personne en dehors de la QA ne lit jamais les fichiers .feature. Si le métier n'est pas dans la boucle, le BDD n'est qu'un framework de test plus lent — mieux vaut écrire des tests automatisés simples.

Une data table est une grille attachée à une seule étape — la définition d'étape la reçoit comme des données structurées à parcourir. « Given les produits suivants : » puis une table de noms et de prix, utilisée une fois dans ce scénario.

Une table Examples est différente : elle appartient à un Scenario Outline et exécute tout le scénario une fois par ligne. Règle générale — une data table passe plusieurs valeurs dans une étape ; Examples exécute un scénario plusieurs fois. Les confondre est une erreur courante de débutant.

Non. Cucumber est un outil qui exécute Gherkin ; le BDD est la pratique de spécifier le comportement de façon collaborative. Vous pouvez faire du vrai BDD avec SpecFlow, Behave, JBehave, ou sans aucun outil Gherkin — une conversation au tableau et de l'example mapping avant de coder, c'est du BDD.

De même, vous pouvez utiliser Cucumber et faire zéro BDD, si vous écrivez les fichiers feature seul après que le code existe. L'outil n'est ni nécessaire ni suffisant. Les examinateurs posent cette question pour séparer les gens qui ont adopté un outil de ceux qui comprennent la pratique.