What is behaviour-driven development?
Behaviour-driven development is a way of specifying software in terms of observable behaviour, not implementation. Each requirement is captured as a concrete scenario — typically written as Given / When / Then — that describes a starting context, an action, and the expected outcome. The same scenario serves two jobs at once: it's the specification a team agrees on, and it's the automated test that proves the code delivered it.
BDD grew out of test-driven development in the mid-2000s. Dan North coined the term to shift focus from "testing methods" to "specifying behaviour". Two decades later it's the most widely adopted way to describe product behaviour precisely enough for both a person and a machine to act on it.
Why BDD matters more with AI
AI coding agents are fast writers and poor mind-readers. Given a vague prompt, they'll produce plausible code that confidently misses the point. Given a precise BDD scenario, they'll produce code that behaves exactly as specified — and generate the tests that prove it.
As agents get better at writing code, the bottleneck moves upstream to defining what should be built. BDD is the format that makes that definition unambiguous, reviewable, and executable.
What a BDD scenario looks like
BDD scenarios are written in a three-part form — a starting context, a trigger, and an observable outcome — usually expressed as Given / When / Then. Read aloud, a scenario is a product requirement; executed by a test runner, it's a passing or failing check. That duality is the whole point.
For the syntax itself — the structure, worked examples, and the mistakes that quietly break scenarios — read the complete Given / When / Then guide.
BDD vs unit tests vs QA scripts
Unit tests verify a function in isolation. QA scripts document manual steps for a human tester. BDD scenarios sit between them: high-level enough for product and design to agree on, precise enough to run automatically.
A healthy codebase has all three. But only BDD scenarios can serve as the shared source of truth across product, engineering, and QA — and only BDD scenarios read cleanly to an AI agent as intent.
How BDD fits inside spec-driven development
BDD is the verification layer of a broader spec-driven development workflow. Spec-driven development adds two things around it: a structured taxonomy so every scenario has a home, and jobs-to-be-done context so every scenario is anchored to a real user need. BDD alone answers does the software behave correctly? Spec-driven development answers are we building the right thing, and does it behave correctly?
If you're already writing Gherkin, you're most of the way to spec-driven development. If you're only writing PRDs, BDD is the missing verification layer — here's why the PRD alone doesn't cut it anymore.
How Executable implements BDD
Executable treats verification as part of the specification rather than a downstream chore: every scenario you write is both the agreed requirement and the check that proves it shipped, synced to your repo so the test runner and the product team read the same file.
Frequently asked questions
What is behaviour-driven development?
Behaviour-driven development (BDD) is a practice where product behaviour is described in concrete, testable scenarios — typically Given / When / Then — that act as both specification and automated test. If the code passes the scenario, it matches the intent.
How is BDD different from unit testing?
Unit tests verify small pieces of code. BDD scenarios verify user-visible behaviour. A BDD scenario reads like a product requirement; a unit test reads like implementation. Both matter, but BDD is the layer product, engineering, and QA can share.
Do I need Cucumber or Gherkin to do BDD?
No. Gherkin (Given/When/Then) is the most common notation, and Cucumber is the most common runner, but the practice is independent of the tool. What matters is that behaviour is described unambiguously and can be verified automatically.
How does BDD fit with AI coding agents?
Modern AI coding agents write code fast but interpret intent inconsistently. A BDD scenario is a precise, machine-readable statement of intent — exactly the input an agent needs to generate code that behaves the way you asked.