Module
Module 3 sur 5Leçon 1 sur 2~18 min

Écrire des critères Given / When / Then vérifiables

Des critères d'acceptation flous se discutent à la recette, alors que des scénarios précis se vérifient, par un testeur comme par un agent de code. Cette leçon vous apprend à rédiger des scénarios Given/When/Then rigoureux, lisibles par toute l'équipe et faciles à transformer en tests automatisés.

Objectif de la leçon

À la fin de cette leçon, vous serez capable d'écrire des scénarios Given/When/Then vérifiables et déclaratifs (contexte minimal, un seul événement, résultats observables), de les nommer par ce qui les distingue et de regrouper des variantes dans un tableau d'exemples.

Thèmes abordés

  • Given When Then
  • critères d'acceptation
  • BDD
  • Gherkin
  • scénarios de test

Dans quel module

Critères, cas limites et exigences

Comment écrire des critères qu'on peut vérifier, et ne pas oublier ce qui arrive quand tout ne se passe pas comme prévu ?

Leçons du module

  1. Écrire des critères Given / When / Then vérifiables (cette leçon)
  2. Cas limites et exigences non fonctionnelles

Ce que vous apprendrez dans la formation

Cette leçon fait partie de la formation Écrire des specs que les développeurs et les agents IA comprennent

  • Choisir le niveau de spec adapté à la décision à prendre (PRD, spec de fonctionnalité, ticket) et savoir ce que chacun doit contenir.
  • Formuler l'intention d'une fonctionnalité (problème, résultat visé, contraintes, non-objectifs) séparément de la solution, pour laisser la bonne marge à l'équipe et à l'agent.
  • Écrire des critères d'acceptation Given/When/Then vérifiables, déclaratifs et sans ambiguïté, y compris sous forme de tableaux d'exemples.
  • Identifier les cas limites et les exigences non fonctionnelles (performance, sécurité, accessibilité, données personnelles) et les rendre testables.
  • Rédiger une spec et un fichier d'intention exploitables par un agent de code (contexte, contraintes, fichiers concernés, hors périmètre, définition de terminé vérifiable).
  • Relire le plan d'un agent de code contre la spec, repérer les écarts avant qu'il code, puis vérifier les preuves de ce qui a été livré.
  • Garder une spec vivante (versions, décisions, mises à jour quand le code révèle un cas) et repérer les anti-patterns qui la rendent inutile.