Générer des tests Gherkin avec l’IA grâce au few-shot

Pour générer des tests Gherkin avec l’IA, fournissez des règles validées, le vocabulaire du domaine, les conventions du projet et quelques scénarios exemplaires. Cette approche few-shot stabilise la forme, mais elle peut aussi reproduire les défauts des exemples. Auditez donc les modèles fournis, exigez un lien vers chaque critère, validez la syntaxe avec le parseur Gherkin et n’appelez le fichier « exécutable » qu’après liaison aux définitions de pas.

Gherkin, Cucumber et BDD : trois notions à ne pas confondre

Gherkin désigne un langage structuré en texte brut qui utilise des mots-clés pour décrire des fonctionnalités, des règles, des exemples et des étapes.

Cucumber désigne un ensemble d’outils capables d’interpréter des documents Gherkin et de relier leurs étapes à du code appelé définition de pas.

Le Behavior-Driven Development (BDD) désigne une pratique collaborative centrée sur la compréhension partagée du comportement attendu à travers des exemples concrets. Écrire du Gherkin ne suffit pas, à lui seul, à démontrer qu’une équipe pratique le BDD.

La référence officielle Gherkin de Cucumber précise la structure des mots-clés et l’exécution séquentielle des étapes. Un scénario devient une spécification exécutable dans un projet Cucumber lorsque ses étapes correspondent à des définitions de pas et que les assertions vérifient les résultats attendus.

Qu’est-ce que le few-shot prompting appliqué à Gherkin ?

Le few-shot prompting désigne le fait de fournir quelques exemples d’entrée et de sortie afin de guider le modèle sur une nouvelle tâche. Pour Gherkin, les exemples montrent le vocabulaire, le niveau d’abstraction, la structure, les tags et la traçabilité attendus.

Le nombre optimal d’exemples dépend du modèle, de leur taille et de leur complémentarité. Il vaut mieux deux exemples validés qui couvrent des formes différentes que de nombreux scénarios redondants ou discutables.

Ce que de bons exemples doivent démontrer

Un exemple few-shot doit être choisi pour une raison explicite :

• un scénario nominal court ;
• un scénario négatif qui montre le traitement d’une règle ;
• un Plan du scénario avec données tabulaires si le projet l’utilise ;
• les tags et identifiants attendus ;
• le niveau d’abstraction métier ;
• la langue et le vocabulaire de domaine ;
• la manière de relier le scénario au critère source.

La documentation Cucumber recommande des exemples courts et indique généralement 3 à 5 étapes par exemple afin de préserver leur pouvoir expressif. Cette recommandation provient de la référence Cucumber consultée en 2026 ; elle n’est pas une limite syntaxique absolue.

Structure Gherkin française correcte

La localisation officielle Cucumber définit notamment les mots-clés français Fonctionnalité, Contexte, Règle, Scénario ou Exemple, Plan du scénario, Exemples, Soit, Quand, Alors, Et et Mais.

# language: fr
Fonctionnalité: Modification de l’adresse de livraison

  Règle: Un client authentifié peut modifier une adresse valide

    Scénario: Enregistrer une adresse française valide
      Soit un client authentifié sur la page de son profil
      Quand il enregistre une adresse française complète
      Alors la nouvelle adresse est affichée comme adresse de livraison

L’en-tête # language: fr indique la langue à l’analyseur. Le texte des étapes doit suivre le vocabulaire de l’équipe et rester stable si des définitions de pas existent déjà.

Méthode en 4 étapes pour générer des scénarios Gherkin par IA

Étape 1 — Auditer les exemples few-shot

Objectif : empêcher la reproduction de défauts existants.

Action : vérifier la syntaxe, le vocabulaire, l’observabilité des Alors, la longueur, les détails d’interface, les doublons et la trace vers les règles.

Résultat attendu : un petit ensemble d’exemples approuvés et annotés selon ce qu’ils démontrent.

Erreurs à éviter : fournir un scénario simplement parce qu’il passe aujourd’hui ; mélanger plusieurs styles ; conserver des résultats attendus vagues.

Étape 2 — Construire le prompt avec les sources et conventions

Objectif : séparer les règles métier de la démonstration de format.

Action : fournir la user story, les critères validés, le glossaire, la liste des étapes existantes si leur réutilisation est souhaitée et les exemples few-shot.

Résultat attendu : un prompt qui indique ce qui fait autorité, ce qui doit être imité et ce qui ne doit pas être copié.

Erreurs à éviter : laisser les exemples introduire une règle absente ; demander « tous les scénarios » ; omettre la langue Gherkin.

Étape 3 — Générer avec traçabilité et liste des exclusions

Objectif : produire un fichier relisible et expliquer la couverture.

Action : exiger un tag ou un commentaire d’identifiant par règle, une justification des scénarios fusionnés ou rejetés et une liste séparée des inconnues.

Résultat attendu : des scénarios reliés aux critères, sans règles inventées.

Erreurs à éviter : multiplier les cas équivalents ; introduire des données personnelles ; transformer une hypothèse en Alors.

Étape 4 — Vérifier syntaxe, définitions de pas et couverture

Objectif : distinguer texte plausible et artefact utilisable.

Action : analyser le fichier avec l’outil Gherkin du projet, vérifier les étapes non définies ou ambiguës, exécuter les scénarios, contrôler les assertions et relire la couverture avec le métier.

Résultat attendu : un fichier syntaxiquement valide, relié à des étapes sans ambiguïté et exécuté avec des résultats examinés.

Erreurs à éviter : qualifier le fichier d’exécutable après une simple revue visuelle ; ignorer les définitions de pas dupliquées ; confondre succès technique et règle correcte.

Prompt few-shot prêt à adapter

RÔLE
Tu assistes un test analyst pour transformer des critères validés en scénarios Gherkin français.
Tu produis un brouillon soumis à revue et à exécution.

SOURCES D’AUTORITÉ
- STORY : contexte du besoin.
- CRITERES : seules règles autorisées pour les résultats attendus.
- GLOSSAIRE : vocabulaire métier à employer.

CONVENTIONS
- Langue : fr.
- Un comportement principal par scénario.
- Étapes au niveau métier, sans sélecteur ni détail d’implémentation.
- Chaque `Alors` décrit un résultat observable.
- Tag `@AC_<id>` pour la traçabilité.
- Réutilise les formulations d’étapes existantes lorsqu’elles sont applicables.

EXEMPLES VALIDÉS
<EXEMPLE_1 objectif="scénario nominal et niveau métier">
[scénario validé]
</EXEMPLE_1>
<EXEMPLE_2 objectif="plan du scénario et données limites">
[scénario validé]
</EXEMPLE_2>

TÂCHE
1. Liste les critères couverts et les inconnues.
2. Génère le minimum de scénarios nécessaires à la couverture demandée.
3. Indique les scénarios fusionnés ou exclus avec justification.
4. N’invente aucune règle absente de CRITERES.

FORMAT
Bloc `.feature`, puis tableau : scénario | critère | objectif | contrôle restant.

Exemple hypothétique 1 — Changement d’adresse avec un plan de scénario

Règles validées

• AC-1 : un client authentifié peut enregistrer une adresse avec pays obligatoire ;
• AC-2 : pour la France, le code postal accepté contient exactement cinq chiffres ;
• AC-3 : une valeur invalide empêche l’enregistrement et affiche un message.

Sortie Gherkin proposée

# language: fr
@adresse
Fonctionnalité: Modifier l’adresse de livraison

  Règle: Une adresse française exige un code postal de cinq chiffres

    @AC_2 @AC_3
    Plan du scénario: Refuser un code postal français invalide
      Soit un client authentifié qui modifie son adresse de livraison
      Et que le pays sélectionné est "France"
      Quand il saisit le code postal "<code_postal>" et enregistre l’adresse
      Alors l’adresse n’est pas enregistrée
      Et un message indique que le code postal français doit contenir cinq chiffres

      Exemples:
        | code_postal |
        | 7500        |
        | 750001      |
        | 75A01       |

Ce scénario illustre des partitions invalides, pas toutes les règles du formulaire. Le testeur doit confirmer que le message exact constitue bien un attendu validé. Si le critère exige seulement « un message d’erreur », le texte précis ne doit pas être inventé.

Exemple hypothétique 2 — Remboursement bloqué par une décision manquante

La user story indique qu’un remboursement passe par un prestataire externe, mais ne définit pas le comportement en cas de délai dépassé. L’IA pourrait produire :

Alors le remboursement est automatiquement relancé après 24 heures

Cette étape est incorrecte si aucune source ne définit le délai ou la reprise. La bonne sortie n’est pas un scénario complété, mais un blocage explicite :

Scénario non généré : comportement après expiration du délai indéterminé.
Question : quel statut afficher, qui relance et après quelle durée ?
Critère concerné : absent des sources fournies.

Une fois la décision validée, le scénario peut être généré et relié à son nouvel identifiant. Le refus de générer est ici un signe de qualité.

Comment vérifier la qualité des scénarios générés

Syntaxe

• le fichier est accepté par le parseur de la version utilisée ;
• les mots-clés et deux-points sont correctement placés ;
• chaque Plan du scénario possède un bloc Exemples ;
• chaque paramètre <nom> correspond à un en-tête de colonne.

Sens métier

• chaque scénario illustre une règle validée ;
• les préconditions sont suffisantes mais non procédurales ;
• l’action représente un événement identifiable ;
• le résultat est observable par un utilisateur ou un système externe ;
• aucun détail ne vient d’une simple habitude du modèle.

Automatisation

• chaque étape correspond à une définition de pas unique ;
• les définitions ne se distinguent pas seulement par Soit, Quand ou Alors, car Cucumber ne tient pas compte du mot-clé pour faire correspondre le texte d’une étape ;
• les assertions évaluent le résultat attendu ;
• les scénarios sont indépendants et les données contrôlées ;
• l’exécution a réellement eu lieu dans l’environnement défini.

Couverture et maintenance

• les critères sont reliés aux scénarios ;
• les doublons sont supprimés ;
• les Exemples représentent des partitions justifiées ;
• les détails d’interface sont évités lorsqu’ils n’expriment pas le métier ;
• les scénarios rejetés ou fusionnés sont documentés.

Erreurs fréquentes avec l’IA et Gherkin

Fournir des exemples non audités

Le few-shot imite volontiers le vocabulaire et la structure montrés. Un scénario trop procédural, un Alors vague ou une mauvaise trace se répète. Faites passer les exemples par la même revue que la sortie attendue.

Confondre validité syntaxique et qualité du test

Un parseur peut accepter un scénario qui vérifie la mauvaise règle. Contrôlez séparément syntaxe, correspondance aux définitions de pas, assertions et couverture métier.

Écrire des étapes centrées sur l’interface

Des étapes comme « cliquer sur le bouton bleu à droite » deviennent fragiles et cachent l’intention. Décrivez l’action métier, sauf si le détail d’interface constitue précisément l’objet du test.

Générer un scénario par ligne de critère

La correspondance mécanique crée doublons et scénarios artificiels. Une règle peut nécessiter plusieurs exemples ; un exemple peut démontrer plusieurs résultats cohérents. Justifiez la relation plutôt que d’imposer un ratio.

Inventer le texte des messages

Le modèle complète souvent un message vraisemblable. Si le libellé exact n’est pas validé, vérifiez seulement la propriété prévue par le critère ou posez une question au responsable produit.

Appeler le fichier « exécutable » avant exécution

Un document Gherkin sans définitions de pas correspondantes ne constitue pas encore un test automatisé exécuté. Vérifiez les étapes, les assertions, l’environnement et le résultat de la commande Cucumber.

Conclusion

Le few-shot améliore la cohérence d’une génération Gherkin seulement si les exemples méritent d’être imités. Auditez-les, séparez format et règles métier, exigez la traçabilité, puis validez le fichier avec le parseur et l’exécution du projet. Pour industrialiser cette chaîne sans dégrader votre patrimoine BDD, vous pouvez faire auditer vos scénarios et conventions.