Le Développement piloté par le comportement (BDD) a fondamentalement changé la façon dont les équipes conçoivent la qualité logicielle en rendant les tests lisibles par tous ! Utiliser Cucumber pour les tests BDD est une compétence qui fait le pont entre les exigences métier et l'implémentation technique, créant une documentation vivante qui est réellement exécutée. Si vous avez eu des difficultés avec des cas de test qui deviennent obsolètes dès qu'ils sont écrits, ce guide vous montrera une meilleure approche.
Qu'est-ce que Cucumber et le BDD ?
Cucumber est un outil open-source qui exécute des tests automatisés écrits en langage naturel. Il implémente le Développement piloté par le comportement (BDD), une méthodologie où les développeurs, les testeurs et les parties prenantes métier collaborent pour définir le comportement logiciel à l'aide d'exemples concrets.
Le BDD se concentre sur une question : "Que doit faire le système ?" plutôt que "Comment devons-nous le tester ?" Le résultat est un langage partagé qui élimine les malentendus et crée des tests servant à la fois de spécifications et de validation exécutable.
Cucumber lit les fichiers .feature contenant des scénarios écrits en syntaxe Gherkin et les exécute en regard de définitions d'étapes – du code qui réalise l'automatisation réelle. Cette séparation signifie que les parties prenantes métier peuvent examiner les scénarios de test sans lire le code, tandis que les développeurs implémentent les détails techniques séparément.
Installation de Cucumber pour JavaScript
La configuration de Cucumber dans un projet Node.js ne nécessite que quelques commandes :
Prérequis :
- Node.js
- NPM
- Un projet API qui possède une fonctionnalité de connexion que nous allons tester (Ce tutoriel ne couvrira que l'installation de Cucumber et les tests Gherkin).
# Créer un nouveau répertoire de projet
mkdir cucumber-bdd-demo && cd cucumber-bdd-demo
# Initialiser npm
npm init -y
# Installer Cucumber et les dépendances de test
npm install --save-dev @cucumber/cucumber chai axios
Votre fichier package.json devrait inclure un script de test :
{
"scripts": {
"test": "cucumber-js"
}
}
Créez cette structure de répertoires :
project/
├── features/
│ └── user-management.feature
├── step-definitions/
│ └── user-steps.js
├── package.json
└── cucumber.json
Guide Pratique : Écrire Votre Premier Test BDD
Construisons un test pour une API de gestion d'utilisateurs afin de démontrer Comment Utiliser Cucumber pour les Tests BDD en pratique.
Étape 1 : Écrire le Fichier de Fonctionnalité
Créez features/user-management.feature :
Fonctionnalité: API de gestion des utilisateurs
En tant que client API
Je souhaite gérer les utilisateurs
Afin de pouvoir intégrer la fonctionnalité utilisateur dans mon application
Scénario: Créer un nouvel utilisateur avec succès
Étant donné que j'ai une charge utile utilisateur valide
Quand j'envoie une requête POST à "/api/users"
Alors le statut de la réponse devrait être 201
Et la réponse devrait contenir un ID utilisateur
Scénario: Tenter de créer un utilisateur avec un e-mail invalide
Étant donné que j'ai une charge utile utilisateur avec un e-mail invalide
Quand j'envoie une requête POST à "/api/users"
Alors le statut de la réponse devrait être 400
Et la réponse devrait contenir "Format d'e-mail invalide"
Étape 2 : Implémenter les Définitions d'Étapes
Créez step-definitions/user-steps.js :
const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai');
const axios = require('axios');
let requestPayload;
let response;
Given('I have a valid user payload', function() {
requestPayload = {
name: 'Test User',
email: 'test@example.com',
password: 'ValidPass123'
};
});
Given('I have a user payload with invalid email', function() {
requestPayload = {
name: 'Test User',
email: 'invalid-email',
password: 'ValidPass123'
};
});
When('I send a POST request to {string}', async function(endpoint) {
try {
response = await axios.post(`http://localhost:3000${endpoint}`, requestPayload);
} catch (error) {
response = error.response;
}
});
Then('the response status should be {int}', function(statusCode) {
expect(response.status).to.equal(statusCode);
});
Then('the response should contain a user ID', function() {
expect(response.data).to.have.property('userId');
expect(response.data.userId).to.match(/^[0-9a-fA-F]{24}$/);
});
Then('the response should contain {string}', function(message) {
expect(response.data.message).to.include(message);
});
Étape 3 : Modifier le fichier Cucumber.json
Créez un fichier "cucumber.json" dans le répertoire racine de votre projet et ajoutez le code suivant :
{
"default": {
"formatOptions": {
"snippetInterface": "synchronous"
}
}
}Étape 4 : Exécuter les Tests
Exécutez vos tests avec :
npm test
Cucumber affichera des résultats détaillés indiquant quelles étapes ont réussi, sont indéfinies ou ont échoué.
Règles pour Écrire de Bons Scénarios BDD
Apprendre à utiliser efficacement Cucumber pour les Tests BDD nécessite de suivre ces règles éprouvées :
1. Structure Étant donné-Quand-Alors
Chaque scénario doit avoir ces trois parties dans l'ordre :
- Étant donné : Établit les préconditions
- Quand : Décrit l'action
- Alors : Valide le résultat
2. Écrire de Manière Déclarative, Pas Impérative
Mauvais :
Étant donné que j'ouvre le navigateur
Et que je navigue vers "/login"
Et que je saisis "test@example.com" dans le champ e-mail
Et que je saisis "motdepasse" dans le champ mot de passe
Et que je clique sur le bouton de connexion
Bon :
Étant donné que je suis sur la page de connexion
Quand je me connecte avec des identifiants valides
Alors je devrais voir le tableau de bord
Concentrez-vous sur ce que vous testez, pas sur la manière de le faire.
3. Un Scénario, Un Objectif
Chaque scénario doit tester un comportement unique. Les scénarios combinés masquent les échecs et rendent le débogage difficile.
4. Utiliser un Langage Métier
Écrivez des scénarios que les parties prenantes métier peuvent comprendre. Évitez le jargon technique et les détails d'implémentation.
5. Rendre les Scénarios Indépendants
Les scénarios ne doivent pas dépendre les uns des autres. Chacun doit configurer ses propres données et les nettoyer ensuite.
Fonctionnalités Avancées de Cucumber : Tables de Données et Plans de Scénario
Tables de Données pour les Entrées Complexes
Lorsque vous avez besoin de tester avec plusieurs points de données, utilisez des tables :
Scénario: Créer des utilisateurs avec différents rôles
Étant donné que j'ai les données utilisateur suivantes :
| nom | e-mail | rôle |
| Alice | alice@example.com | admin |
| Bob | bob@example.com | utilisateur |
Quand j'envoie une requête POST à "/api/users"
Alors tous les utilisateurs devraient être créés avec succès
Définition d'étape :
Given('I have the following user data:', function(dataTable) {
requestPayload = dataTable.hashes();
});
Plans de Scénario pour les Tests Basés sur les Données
Lorsque vous souhaitez exécuter le même scénario avec des données différentes, utilisez des plans de scénario :
Plan de Scénario: Connexion avec divers identifiants
Étant donné que je suis sur la page de connexion
Quand je saisis "" et ""
Alors je devrais voir ""
Exemples :
| e-mail | motdepasse | résultat |
| test@example.com | validPass | Tableau de bord |
| test@example.com | wrongPass | Mot de passe invalide|
| invalid@email.com | validPass | E-mail invalide |
Cela crée automatiquement trois scénarios de test distincts.
Organisation des Tests avec des Balises
Les balises vous aident à catégoriser et filtrer les scénarios :
@smoke @regression
Scénario: Connexion utilisateur
Étant donné que je suis sur la page de connexion
Quand je me connecte avec des identifiants valides
Alors je devrais voir le tableau de bord
@api @critical
Scénario: Vérification de l'état de l'API
Étant donné que l'API est en cours d'exécution
Quand je requiers "/health"
Alors le statut de la réponse devrait être 200
Exécutez uniquement des balises spécifiques :
npm test -- --tags "@smoke"
Comment Apidog Aide aux Tests API dans les Flux de Travail BDD
Alors que Cucumber excelle à définir le comportement, Apidog automatise le travail fastidieux de création et d'exécution des tests API, rendant les tests Cucumber pour BDD beaucoup plus efficaces.
Génération de Cas de Test API Alimentée par l'IA
Au lieu d'écrire manuellement des définitions d'étapes pour les appels API, Apidog les génère à partir de votre spécification OpenAPI en utilisant l'IA :
# Votre spécification API
paths:
/api/users:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
name: string
email: string
responses:
'201':
description: User created
Apidog crée automatiquement des scénarios prêts à être testés :
- Test positif : Charge utile valide → statut 201
- Test négatif : E-mail invalide → statut 400
- Test de limite : Champ requis manquant → statut 400
Foire Aux Questions
Q1 : Ai-je besoin de savoir programmer pour écrire des tests Cucumber ?
Rép : Écrire des scénarios Gherkin ne nécessite aucune programmation — juste une pensée claire sur le comportement. Cependant, l'implémentation des définitions d'étapes requiert des connaissances en JavaScript (ou autre langage). Des outils comme Apidog réduisent cette charge en générant automatiquement le code de définition d'étape.
Q2 : En quoi Cucumber est-il différent des frameworks de test traditionnels ?
Rép : Les frameworks traditionnels (Jest, Mocha) se concentrent sur l'implémentation technique. Cucumber se concentre sur le comportement métier. Le même scénario Cucumber peut piloter des tests d'interface utilisateur web (Selenium), des tests API (Axios) ou des tests mobiles (Appium) sans modifier le texte Gherkin.
Q3 : Cucumber peut-il remplacer les outils de test API ?
Rép : Cucumber fournit la structure de test, mais vous avez toujours besoin d'outils pour exécuter les appels API (Axios, Supertest) et valider les réponses. Apidog complète Cucumber en gérant la couche d'exécution API tandis que Cucumber gère le flux de travail BDD.
Q4 : Qu'est-ce qui fait un bon scénario Cucumber ?
Rép : Les bons scénarios sont indépendants, utilisent un langage métier, suivent la structure Étant donné-Quand-Alors, et testent un comportement chacun. Ils doivent être lisibles par les parties prenantes non techniques et se concentrer sur ce que fait le système, pas sur la façon dont il le fait.
Q5 : Comment Apidog gère-t-il l'authentification dans les tests BDD ?
Rép : Apidog gère automatiquement les jetons d'authentification. Vous pouvez définir des étapes "Étant donné que je suis authentifié" qui utilisent la gestion des identifiants d'Apidog pour récupérer des jetons valides, éliminant ainsi la gestion manuelle des jetons dans vos définitions d'étapes.
Conclusion
L'utilisation de Cucumber pour les tests BDD transforme efficacement votre processus de développement en créant une compréhension partagée entre les équipes techniques et métier. La syntaxe Gherkin impose la clarté, tandis que la séparation des scénarios et des définitions d'étapes maintient les tests gérables à mesure que votre application évolue.
La véritable puissance vient de l'intégration de Cucumber avec des outils d'automatisation modernes. Apidog élimine le travail manuel fastidieux d'écriture de code de test API, vous permettant de vous concentrer sur la définition de comportements significatifs pendant qu'il gère l'exécution. Cette combinaison offre le meilleur des deux mondes : des spécifications lisibles par l'homme qui servent de documentation vivante, et des tests automatisés robustes qui s'exécutent en continu.
Commencez petit. Choisissez un point de terminaison API. Écrivez trois scénarios : succès, échec et cas limite. Implémentez les définitions d'étapes. Exécutez-les. Montrez les résultats à votre chef de produit. Une fois qu'ils verront les exigences métier exécutées sous forme de tests, vous obtiendrez l'adhésion pour étendre le BDD à l'ensemble de votre projet. C'est alors que l'utilisation de Cucumber pour les tests BDD cesse d'être une pratique technique et devient un mouvement qualité à l'échelle de l'équipe.