Behavior-Driven Development (BDD) is Dan North's practice, introduced in 2006, of specifying system behavior through concrete examples that double as executable tests. Scenarios follow the Given-When-Then format, often written in Gherkin syntax, in a ubiquitous language that developers, testers and business representatives can work out together, for example in Three Amigos sessions. The scenarios serve as executable acceptance criteria and as living documentation that stays current with the system.

BDD (Behavior-Driven Development)

Details
Also known as

Specification by Example, Executable Specifications

Core Concepts:

Given-When-Then

Structured scenario format — Given a precondition, When an action occurs, Then an expected outcome results

Specification by Example

Concrete examples as executable specifications that define system behavior

Three Amigos

Collaborative discovery sessions between developer, tester, and business representative

Gherkin syntax

Domain-specific language for writing human-readable, machine-executable scenarios

Living documentation

Tests that serve as always-current system documentation

Outside-in specification

Start from desired business behavior, work inward to implementation

Ubiquitous language

Shared vocabulary bridging technical and business stakeholders in scenarios

Discovery workshops

Structured conversations to uncover requirements through examples before implementation

Key Proponent

Dan North ("Introducing BDD", 2006), creator of JBehave which influenced Cucumber’s design (Cucumber created by Aslak Hellesøy, 2008)

When to Use:

  • Cross-functional teams needing shared understanding of requirements

  • Systems where business rules are complex and need clear documentation

  • Projects requiring executable acceptance criteria

  • Bridging communication gaps between technical and non-technical stakeholders