Gherkin
Gherkin is a structured plain-English DSL for writing executable acceptance tests, using the Given / When / Then format. It originated with Cucumber and is now used across BDD frameworks (SpecFlow, Behat, pytest-bdd). Gherkin is readable by non-developers but parsable by test runners.
A typical Gherkin scenario reads: 'Given I am viewing the project board / When I select 5 issues and click Archive / Then the issues disappear and an undo toast appears.' The format's strength is bridging product and engineering: PMs can write or review the scenarios, engineers can execute them. Anti-patterns: leaking implementation into the steps (mentions of databases, services, or APIs), or writing scenarios so detailed they become test scripts rather than behaviour specifications.
Long-form posts that explore gherkin in depth — when to use it, common failure modes, how AI helps.
- How AI writes acceptance criteria (and where it fails)The honest map of where AI is dramatically better than humans at writing acceptance criteria — and the five places it confidently writes garbage. Plus the prompts that work.10 min read
- Are AI-generated test cases worth shipping?Yes, with a sharp caveat — when they're tied to AC and reviewed by a human. Five categories where AI test generation is great, five anti-patterns to catch.9 min read
- Can AI write Gherkin? (yes — here's how)Yes. AI writes Gherkin well, often better than humans for surface area coverage. Five wins, five recognisable failure modes, and the prompts that work.8 min read
Related terms
- Acceptance criteria
Acceptance criteria are the conditions a story must satisfy to be considered complete — testable, bounded statements describing what the system does.
- Definition of Done
Definition of Done (DoD) is a team-wide checklist that every story must satisfy before being marked complete — typical entries include: code reviewed, tests passing, documentation updated, deployed to staging, AC verified.