Skip to content

Acceptance Test-Driven Development (ATDD)

Overview

Acceptance Test-Driven Development is a collaborative, test-first development methodology where the team writes acceptance tests before any development begins. It expands on TDD and BDD by putting business-defined behaviour at the centre of the process.

ATDD is a process where developers, testers, and business stakeholders collaborate to define:

  • What the system should do
  • How success will be measured
  • What “done” means for each feature

This is done by writing acceptance tests that describe the expected behaviour in concrete, example-driven language. These tests guide the development of the code.

It’s often carried out using tools like:

  • Gherkin + Reqnroll / SpecFlow (C#)
  • Cucumber
  • FitNesse
  • Robot Framework

What Problem ATDD Solves

ATDD primarily solves communication and alignment issues.

Without ATDD:

  • Developers guess the requirements
  • Testers interpret them differently
  • The business meant something else entirely
  • Rework and bugs pile up
  • Features aren’t actually what the business wanted

With ATDD:

  • Everyone agrees upfront
  • Requirements become executable specifications
  • No guessing
  • Less rework
  • Higher confidence in quality

How ATDD Works (Lifecycle)

  1. Discuss The team talks through the story and defines acceptance criteria together.

  2. Write acceptance tests Usually in Gherkin, e.g.:

Given a user has an empty basket
When they add a product costing £10
Then the basket total should be £10

  1. Automate the tests Bind them to C# step definitions and automation code.

  2. Write the code The code is developed just enough to make the acceptance test pass.

  3. Refactor Improve the design while keeping the tests green.

  4. Deliver The acceptance tests remain as living documentation.

Advantages of ATDD

  • Better alignment - The business, test team, and developers agree before coding begins.
  • Fewer defects - Ambiguity is removed early.
  • Tests become “living documentation” - The Gherkin files describe what the system actually does.
  • Encourages modular, testable code - Developers code to make acceptance criteria pass.
  • Works extremely well with microservices - Especially with contract tests and API acceptance tests.
  • Drives quality early - ATDD moves testing "left" in the delivery process.

Disadvantages / Challenges

  • Requires collaboration time - Teams unused to the approach may think it slows them down.
  • Can produce poor tests if Gherkin is misused - Bad Gherkin leads to brittle automation and unclear behaviour.
  • Needs discipline - ATDD only works if all three amigos (Dev, QA, Product Owner) are actively engaged.
  • Steep learning curve - Writing good acceptance tests is a skill.

How It Relates to BDD and TDD

Practice Focus Who writes scenarios/tests? Level
TDD Design & code Developers Unit tests
BDD Behaviour & collaboration Dev, QA, PO Scenarios
ATDD Acceptance & delivering the right thing Dev, QA, PO Acceptance tests

ATDD and BDD are very similar, but:

  • ATDD focuses on requirements and acceptance criteria
  • BDD emphasises the behaviour of the system and domain language

In practice, teams often use the terms interchangeably.

Summary

ATDD = Acceptance tests first + collaboration + executable requirements.

It ensures you build the right thing, not just build something well.