What is Acceptance-Test-Driven Development (ATDD)?
ATDD writes the acceptance tests collaboratively — customer, developer, tester together — before development begins: the team agrees what "passing" looks like, automates those checks, then builds until they're green. BDD is its best-known dialect (Given/When/Then phrasing).
The shift it causes is conversational: ambiguity gets argued out in the specification workshop instead of discovered in the demo. Code review catches bad code; ATDD catches bad requirements — earlier and cheaper.
Worked example
Before building loyalty discounts, the three amigos write the acceptance tests: gold member + $100 cart = $90; discounts don't stack with promo codes; downgraded members keep benefits until month-end. That third test triggers a ten-minute argument nobody knew they needed — resolved on a whiteboard, not in production, which is the entire economics of ATDD.