Behavior-Driven Development

Also known as: BDD

practice · computer science · organizing-schema

TDD variant using natural-language scenarios to specify behavior.

Behavior-Driven Development was articulated by Dan North beginning in 2003 as a deliberate evolution of Test-Driven Development that addresses what North argued was TDD's framing problem: unit tests are easily understood as testing rather than as specifying behavior, with the result that they often fail to capture the why of the code. BDD reframes test-first development as specification-first development, expressed in natural-language scenarios using the Given-When-Then template (Given some initial context, When an event occurs, Then ensure outcomes). The Gherkin syntax used by tools including Cucumber, SpecFlow, and Behat operationalizes scenarios as executable specifications that domain experts and developers can read and edit collaboratively. BDD distinguishes itself from TDD primarily through emphasis: where TDD's red-green-refactor focuses on the developer's design feedback loop, BDD's outside-in flow focuses on the conversation among stakeholders, business analysts, and developers, with executable scenarios serving as the shared artifact. The framework has substantial overlap with Acceptance Test-Driven Development (ATDD) and Specification by Example (Adzic).

Originators

Dan North; subsequent contributors including Liz Keogh, Aslak Hellesøy (Cucumber), Gojko Adzic (Specification by Example) high

Year / Decade

2003 (North's initial articulation); 2006 (Cucumber); 2009 (North's 'What's in a Story?') high

Primary sources

North, D. (2006). 'Introducing BDD' (dannorth.net), North, D. (2009). 'What's in a Story?' (dannorth.net), Adzic, G. (2011). Specification by Example high

Core components

Given-When-Then scenario template
Gherkin syntax for executable scenarios
Cucumber and similar BDD tooling
Outside-in development flow
Three-amigos collaboration (business, dev, QA on each story)
Connection to Specification by Example
Living documentation as scenarios remain executable
Distinction from TDD by emphasis on stakeholder communication

Primary use case

Software development with substantial business-stakeholder collaboration; foundation for executable specifications and living documentation; complement to TDD particularly for application-level rather than unit-level behavior; basis for some agile-coaching practices around story refinement; integration with continuous integration pipelines via Cucumber and similar tools.

Common criticisms

BDD scenarios written by developers without genuine domain-expert involvement become indirect unit tests with extra ceremony
Gherkin syntax can produce verbose, brittle scenarios that are harder to maintain than direct unit tests
the promise of business-readable specifications often unrealized as scenarios drift toward implementation language
tooling overhead is substantial — Cucumber and similar add complexity that isn't always justified
works best where genuine collaboration with domain experts is feasible, less well in product-management-mediated organizations
some critics argue BDD is essentially TDD with extra ceremony, with the framework's distinct contribution being communication culture rather than technical practice.

Lineage

Child of: Test-Driven Development
Siblings: Test-Driven Development, Extreme Programming
Derived from: Test-Driven Development