Overview
Behavior-Driven Development (Dan North) reframes TDD around behavior and shared language: examples of how the system should behave, written in terms the business understands, become executable specifications. It closes the gap between requirements and tests — the conversation matters as much as the automation.
Key points
- Given / When / Then: the canonical structure for an example — context, action, expected outcome. Gherkin is the common syntax (Cucumber, SpecFlow, Behave).
- Discovery before formulation before automation: the "three amigos" conversation (business, dev, test) producing concrete examples is the core practice; tooling is secondary.
- Ubiquitous language: scenarios reuse the domain's vocabulary — direct bridge to DDD.
- Double-loop TDD: an outer failing acceptance scenario drives inner red/green/refactor unit cycles (TDD).
- Living documentation: passing scenarios document what the system actually does, and stay honest because they execute.
- Anti-pattern: writing Gherkin as a UI click-script or as thinly disguised unit tests — scenarios should express business intent, not implementation steps.
- To explore: example mapping, specification by example (Gojko Adzic).
Practice
- Cucumber 10-minute tutorial (source) — run the Gherkin toolchain end to end once, so the mechanics never distract again.
- Lift kata (source) — behavior-rich and UI-free; formulate Given/When/Then scenarios that express intent, not click-scripts — the anti-pattern drill.
- Mars Rover, double-loop (source) — one failing acceptance scenario per feature driving inner red/green/refactor cycles.
- Event-sourced bank account (exercise) — Given/When/Then as the native shape of event-sourced tests: given past events, when a command, then new events.
Related
- TDD — BDD grew out of it; the inner loop is still TDD.
- DDD — shares the ubiquitous-language foundation.
- Clean code