In 30 seconds
- TDD: write a failing unit test, make it pass, refactor.
- BDD: describe behaviour in plain language with examples, then automate them.
- Most teams use both: BDD for features, TDD for code.
Pick TDD when…
- Designing code units and their interfaces
- You want fast, fine-grained tests developers rely on
- The audience is mainly developers
Pick BDD when…
- Business people need to read and agree the specifications
- Acceptance criteria are often misunderstood
- You want living documentation of behaviour
Side by side
| TDD | BDD | |
|---|---|---|
| Origin | Kent Beck, XP | Dan North, mid-2000s |
| Cycle | Red, green, refactor | Discover, formulate, automate |
| Language | Code | Given, When, Then |
| Level | Units of code | User-visible behaviour |
| Audience | Developers | Whole team and stakeholders |
Myth vs reality
Myth · BDD replaces TDD.
Reality · They operate at different levels and complement each other.
Myth · BDD means using Cucumber.
Reality · Tools help; the conversation about examples is the core.
Myth · TDD is about testing.
Reality · It's mostly a design technique that leaves tests behind.
FAQ
What is Given-When-Then?
A format for examples: the starting context, the action, the expected result.
Do we need both?
Not always; many teams start with TDD and add BDD where misunderstandings hurt.
Is ATDD the same as BDD?
Very close: both write acceptance tests before code, with business input.