Behavior-Driven Development (BDD) Cheat Sheet

Updated 2026-05-28

Next Topic: Clean Code Practices Cheat Sheet

🧠Study flashcards on this topic122 cards · spaced repetition→

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, 122 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core BDD ConceptsTable 2: Gherkin KeywordsTable 3: Gherkin Structure ElementsTable 4: Step Definitions & ImplementationTable 5: Data Tables & Scenario OutlinesTable 6: BDD Workflow & CollaborationTable 7: BDD Tools & FrameworksTable 8: Tags & FilteringTable 9: Hooks & Setup/TeardownTable 10: Cucumber Expressions & ParametersTable 11: Reporting & Living DocumentationTable 12: BDD Best PracticesTable 13: BDD Anti-PatternsTable 14: BDD vs TDD vs ATDDTable 15: Advanced BDD FeaturesTable 16: Collaboration Patterns

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

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
Behavior-Driven Development	`Feature: User Login` `Scenario: Valid credentials` `Given user on login page`	Agile methodology emphasizing collaboration between developers, testers, and business stakeholders using natural language to define system behavior before coding.
Given-When-Then	`Given account has $100` `When user withdraws $50` `Then balance is $50`	Structured pattern for representing tests where Given sets context, When describes action, Then specifies expected outcome.
Specification by Example	`Example: Withdraw $50 when balance is $100` `Result: Balance becomes $50`	• Practice of illustrating requirements with concrete examples rather than abstract descriptions • examples become executable tests.
Three Amigos	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.
Example Mapping	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.
Ubiquitous Language	Business: "shopping cart" Code: `ShoppingCart` class Tests: "shopping cart"	Shared vocabulary used consistently across business conversations, code, and tests to eliminate translation errors.
Living Documentation	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.
Executable Specification	Feature file is both human-readable requirement and automated test	• Documentation written in a form that can be run as a test, ensuring it never becomes stale • the core artifact of BDD.
Outside-In Development	Write acceptance test (outside) Write unit tests (inside) Implement code to pass both	Development approach starting with high-level behavior tests then working inward to implementation details.
Discovery Workshop	Team discusses user story: "As a user I want to withdraw cash" explores scenarios together	Structured conversation before coding where team explores requirements through examples to uncover assumptions and edge cases.
Acceptance Criteria	User Story: "Withdraw cash" Criteria: "Cannot withdraw more than balance" "ATM dispenses correct amount"	• Conditions that must be met for a feature to be accepted as complete • often expressed as BDD scenarios.
ATDD (Acceptance Test-Driven Development)	Team defines acceptance tests before coding starts; tests drive feature implementation	• Methodology closely related to BDD where acceptance tests define "done" before development; BDD emphasizes behavior language and collaboration • ATDD emphasizes customer-requirement validation.
Deliberate Discovery	"What don't we know yet?" "What assumptions are we making?" Focus on unknowns	BDD principle emphasizing exploring uncertainties early through conversation rather than documenting what's already known.

Table 2: Gherkin Keywords

Gherkin is a structured, human-readable DSL designed to be the shared language between business and technical teams. Mastering all keywords — including the less-obvious Rule, Background, and * — gives you the full expressive range of Gherkin without writing a single line of code.

Keyword	Example	Description
Feature	`Feature: User Authentication` `Ensures secure access`	• Top-level keyword providing high-level description of software feature • groups related scenarios.

The rest of this section is part of the full cheat sheet

Table 3: Gherkin Structure Elements

Beyond the core keywords, Gherkin provides structural elements for passing rich data to step definitions. Understanding doc strings, data tables, and tags unlocks the full power of parameterized, organized, and filterable test suites.

Element	Example	Description
Doc Strings	`When user submits form:` `"""` `{"name": "John"}` `"""`	Multi-line text argument enclosed in `"""` (or backticks) allowing longer text blocks to be passed to step definitions.

The rest of this section is part of the full cheat sheet

Table 4: Step Definitions & Implementation

Step definitions are the bridge between human-readable Gherkin and executable code. Getting them right — proper scoping, reusability, and the choice between regex and Cucumber Expressions — determines whether your BDD suite stays maintainable as it grows.

Concept	Example	Description
Step Definition	`@Given("user has ${int} dollars")` `public void userHasDollars(int amount)`	• Method that links Gherkin step to code • executed when matching step is encountered in feature file.

The rest of this section is part of the full cheat sheet

Table 1: Core BDD Concepts

Concept	Example	Description
Behavior-Driven Development	`Feature: User Login` `Scenario: Valid credentials` `Given user on login page`	Agile methodology emphasizing collaboration between developers, testers, and business stakeholders using natural language to define system behavior before coding.
Given-When-Then	`Given account has $100` `When user withdraws $50` `Then balance is $50`	Structured pattern for representing tests where Given sets context, When describes action, Then specifies expected outcome.
Specification by Example	`Example: Withdraw $50 when balance is $100` `Result: Balance becomes $50`	• Practice of illustrating requirements with concrete examples rather than abstract descriptions • examples become executable tests.
Three Amigos	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.
Example Mapping	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.
Ubiquitous Language	Business: "shopping cart" Code: `ShoppingCart` class Tests: "shopping cart"	Shared vocabulary used consistently across business conversations, code, and tests to eliminate translation errors.
Living Documentation	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.
Executable Specification	Feature file is both human-readable requirement and automated test	• Documentation written in a form that can be run as a test, ensuring it never becomes stale • the core artifact of BDD.
Outside-In Development	Write acceptance test (outside) Write unit tests (inside) Implement code to pass both	Development approach starting with high-level behavior tests then working inward to implementation details.
Discovery Workshop	Team discusses user story: "As a user I want to withdraw cash" explores scenarios together	Structured conversation before coding where team explores requirements through examples to uncover assumptions and edge cases.
Acceptance Criteria	User Story: "Withdraw cash" Criteria: "Cannot withdraw more than balance" "ATM dispenses correct amount"	• Conditions that must be met for a feature to be accepted as complete • often expressed as BDD scenarios.
ATDD (Acceptance Test-Driven Development)	Team defines acceptance tests before coding starts; tests drive feature implementation	• Methodology closely related to BDD where acceptance tests define "done" before development; BDD emphasizes behavior language and collaboration • ATDD emphasizes customer-requirement validation.
Deliberate Discovery	"What don't we know yet?" "What assumptions are we making?" Focus on unknowns	BDD principle emphasizing exploring uncertainties early through conversation rather than documenting what's already known.

Table 2: Gherkin Keywords

Keyword	Example	Description
Feature	`Feature: User Authentication` `Ensures secure access`	• Top-level keyword providing high-level description of software feature • groups related scenarios.

Table 3: Gherkin Structure Elements

Element	Example	Description
Doc Strings	`When user submits form:` `"""` `{"name": "John"}` `"""`	Multi-line text argument enclosed in `"""` (or backticks) allowing longer text blocks to be passed to step definitions.

Table 4: Step Definitions & Implementation

Concept	Example	Description
Step Definition	`@Given("user has ${int} dollars")` `public void userHasDollars(int amount)`	• Method that links Gherkin step to code • executed when matching step is encountered in feature file.