TDD, BDD and ATDD
Remember the SAVE10 bug from lesson one: 10% off even below ₹500. Suppose that before any code was written, someone had written down "Given a ₹499 cart, when I apply SAVE10, then the total stays ₹499." The bug would have had nowhere to hide. Three related practices turn that idea into a habit.
The rule
Write the test first; let the test describe the behaviour.
TDD (test-driven development) is a developer's rhythm at the unit level, called red, green, refactor:
- Red: write a small unit test for behaviour that does not exist yet. It fails.
- Green: write just enough code to make it pass.
- Refactor: tidy the code, keeping the tests green.
BDD (behaviour-driven development) describes behaviour as concrete examples in plain language that business people, testers and developers all read, usually in the Given / When / Then style (often written in a format called Gherkin):
Scenario: SAVE10 does not apply below the minimum
Given my cart subtotal is ₹499
When I apply the coupon SAVE10
Then my total is ₹499
And I see "SAVE10 needs a cart of ₹500 or more"Tools can link each line to automation code, so the same example becomes an executable test.
ATDD (acceptance-test-driven development) puts the team, typically product owner, tester and developer (sometimes called the "three amigos"), together before development to agree the acceptance tests for a story. The story is done when those tests pass.
The shortcut
Tell them apart by who writes what, at what size. One developer, one unit test: TDD. Everyone, plain-language behaviour examples: BDD. The team agreeing a story's acceptance tests before building: ATDD. BDD and ATDD overlap a lot; BDD stresses the shared language, ATDD the agreement.
ATDD: agree the tests
Owner, tester and developer agree: ₹500 gets 10% off, ₹499 gets none, expired coupons are refused.
The trap is writing the tests after the code and calling it TDD. The value comes from the test shaping the code and the conversation, not from the test existing.
Drills
Answer fast — trust the rule.
What is the correct order of the TDD cycle?
Which format is typical for BDD scenarios?
Product owner, tester and developer agree acceptance tests before a story starts. Which practice?
In TDD, why must the new test fail first?
Remember
- Write the test first; let the test describe the behaviour.
- TDD: developer, unit, red-green-refactor. BDD: shared Given/When/Then. ATDD: team agrees acceptance tests first.
- Tests written after the code are not TDD.