Q1 of 21 · BDD / Cucumber
What is BDD, and how does it differ from TDD?
Short answer
Short answer: BDD (Behaviour-Driven Development) extends TDD by writing tests in plain language that all stakeholders can read. TDD focuses on unit-level red-green-refactor cycles; BDD focuses on collaboratively defining behaviour from the user's perspective before any code is written.
Detail
TDD — Test-Driven Development — is a developer practice: write a failing unit test, write just enough code to pass it, refactor. The audience is developers, the language is code, and the scope is a single unit of logic.
BDD shifts focus to behaviour from the user's perspective, using a shared, ubiquitous language (typically Gherkin) that developers, QA, and business stakeholders can all write and read. The goal is to close the gap between what the business wants and what gets built.
Key differences:
| TDD | BDD | |
|---|---|---|
| Primary audience | Developers | All stakeholders |
| Language | Code (JUnit, Jest…) | Plain English (Gherkin) |
| Scope | Single unit | User-facing behaviour / feature |
| Drives | Internal design | Shared understanding of requirements |
| When written | Before coding a unit | Before sprint starts, in 3-amigo sessions |
BDD does not replace unit testing — it adds a layer of executable, human-readable specifications on top. Cucumber, SpecFlow, and Behave are common BDD frameworks that parse Gherkin and map each line to code (step definitions).
A common misconception: BDD is not just "writing tests in Gherkin". The discipline is the conversation — the "3 amigos" (developer, QA, business analyst) discussing and agreeing on behaviour before writing a line of code.