## Definition
A **Gherkin scenario** is an executable behaviour example written in the `Given / When / Then` syntax popularised by Cucumber and adopted across BDD tooling. Origin: Dan North, Liz Keogh, and Chris Matts at ThoughtWorks, later distilled in [[Specification by Example (Adzic)]].
## Structure
```gherkin
Feature: User login
Background:
Given a user "
[email protected]" with password "correct-horse-battery-staple"
Scenario: Successful login returns a session token
When I POST to "/auth/login" with:
| email |
[email protected] |
| password | correct-horse-battery-staple |
Then the response status is 200
And the response body matches schema "LoginSuccess"
And the body field "token" is a non-empty string
```
## Why Three Things Happen When You Hand This to an Agent
1. The agent has a **plan** (one scenario, one implementation chunk).
2. The agent has a **definition of done** (the scenarios pass).
3. *You* have a **review surface** that doesn't require reading the implementation — read the scenarios and the test output.
## What Makes a Scenario Good
- Reads aloud unambiguously.
- Maps 1:1 to a test name.
- Includes at least one *non-obvious property* alongside the happy path — security, idempotency, ordering, rate limit.
## Composition
Modern usage adds the `Rule` keyword (Gherkin 2018+) to group related scenarios under a single business rule.
## Related
- [[Executable Acceptance Criterion]]
- [[Spec-Driven Development]]
- [[Specification by Example (Adzic)]]
- [[Spec-as-Prompt Pattern]]