Behavior-Driven Development (BDD) is an agile software development methodology that extends Test-Driven Development (TDD) by writing test cases in natural language that non-programmers can read. BDD emerged in 2003 when Dan North sought to bridge the gap between business stakeholders and technical teams, creating a shared understanding of requirements through concrete examples. The methodology uses Gherkin syntax—a domain-specific language with keywords like Given-When-Then—to describe system behavior in plain English, transforming these human-readable scenarios into executable specifications that serve as both tests and living documentation. A key insight: BDD is fundamentally a collaboration practice focused on discovering unknowns through conversation (the "Three Amigos" approach), not merely a testing technique, making early discovery workshops more valuable than the automation that follows.
What This Cheat Sheet Covers
This topic spans 16 focused tables and 158 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core BDD Concepts
BDD is as much a communication framework as a testing approach — the shared vocabulary, discovery conversations, and collaboration structure are what make it effective. Understanding these core concepts helps teams avoid the common mistake of treating BDD as just "tests written in English."
| Concept | Example | Description |
|---|---|---|
Feature: User LoginScenario: Valid credentialsGiven user on login page | Agile methodology emphasizing collaboration between developers, testers, and business stakeholders using natural language to define system behavior before coding. | |
Given account has $100When user withdraws $50Then balance is $50 | Structured pattern for representing tests where Given sets context, When describes action, Then specifies expected outcome. | |
Example: Withdraw $50 when balance is $100Result: Balance becomes $50 | • Practice of illustrating requirements with concrete examples rather than abstract descriptions • examples become executable tests. | |
Product Owner + Developer + Tester discuss "What if user has $0 balance?" | Collaboration session involving business, development, and testing perspectives to discover edge cases and clarify requirements through examples. | |
Rule written on yellow card Examples on blue cards Questions on red cards | Workshop technique using colored index cards to organize rules, examples, and questions for a user story. | |
Business: "shopping cart" Code: ShoppingCart classTests: "shopping cart" | Shared vocabulary used consistently across business conversations, code, and tests to eliminate translation errors. | |
Feature files auto-generate HTML reports showing current system behavior | Test scenarios that serve as always up-to-date documentation because they're executed regularly and fail when behavior changes. |