ATDD by Example: A Practical Guide to Acceptance Test-Driven Development
Authors: Markus Gartner
Publisher: Addison-Wesley Professional
Length: 2013
Acceptance test-driven development through collaborative specification, Given–When–Then, acceptance automation, and a modern update for LLMs and CI/CD.
OriginalBrief
The essential idea
Acceptance test-driven development turns requirements into concrete, testable examples before implementation. Its primary value is collaborative specification between business, development, and QA, using examples in business language as a shared contract rather than handing a story down a chain.
The cycle is Discuss, Distill, Develop, and Demo. The team aligns on the user and business outcome, extracts acceptance criteria and examples, implements code and automated checks against those examples, and validates the result using the same contract. Acceptance tests become executable product documentation and complement rather than replace TDD and lower-level testing.
In 2025, LLMs can draft Gherkin scenarios, generate test skeletons for Playwright, Cypress, or API suites, and expose missing edge cases or conflicting requirements. They reduce routine work but do not replace human agreement about business meaning, maintainability, or release accountability.
Decision lens
Key takeaways
Examples specified before code make ambiguous requirements visible early.
ATDD is a cross-functional activity, not a QA task performed after development.
Given–When–Then creates a shared language and an explicit acceptance contract.
Acceptance tests are executable documentation whose readability and maintenance matter.
The Demo step confirms stakeholder meaning and should not disappear behind automation.
LLMs accelerate drafts and coverage discovery but cannot decide the intended outcome.
Workplace experiment
Apply it at work
- 1
Adopt a shared acceptance-criteria format such as Given–When–Then for product work.
- 2
Make Distill a required refinement step before implementation begins.
- 3
Run acceptance tests as a release quality gate in CI/CD.
- 4
Schedule regular suite hygiene to remove duplicates, fix flaky tests, and preserve scenario readability.
Choose one action, define the observable effect, and keep the first test small enough to reverse.
Evidence
Sources and further reading
Additional sources
Channel, aggregator, and commentary links confirm the work; they are not the primary source.