ATDD: Aligning Code with Business Needs Before You Build
Acceptance Test-Driven Development (ATDD) is a communication framework where business, developers, and testers write acceptance tests together *before* coding begins. This ensures everyone understands the requirements.
THE MENTAL MODEL: Acceptance Test-Driven Development (ATDD) is primarily a communication process, not a testing technique. It centers on the conversation between business stakeholders, developers, and testers to create a shared understanding of requirements before any implementation begins. The acceptance tests are the tangible output of this collaborative discussion.
HOW IT WORKS: ATDD is based on a collaborative meeting (often called a "Three Amigos" meeting) involving a business representative, a developer, and a tester. They discuss a feature or user story and define concrete examples of its expected behavior. These examples are then formalized into acceptance tests, often written in a format understandable by non-technical stakeholders. These tests guide development and serve as the ultimate definition of "done."
WHEN TO USE IT: Use ATDD to bridge the gap between abstract business requirements and concrete technical implementation. It is highly effective for ensuring new features deliver the intended business value and behave exactly as the customer expects. The process helps teams avoid ambiguity, reduce rework, and build the right software by clarifying requirements upfront.
WHEN NOT TO USE IT: ATDD's value is minimal without active collaboration between business, development, and testing. If business stakeholders are unavailable for discussion, or if requirements are handed down without an opportunity for clarification, the core benefit of building a shared understanding is lost. It is a process for discovery, not for verifying static, unchangeable specifications.
ONE CANONICAL EXAMPLE: A product owner, developer, and QA engineer meet to discuss a new "shopping cart checkout" feature. They talk through scenarios: a successful purchase with a valid credit card, a failed purchase with an expired card, and an attempt to use a discount code twice. For each scenario, they agree on the exact system behavior. These agreed-upon examples become the acceptance tests that drive development and confirm the feature is complete.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.