There is often some confusion between Acceptance Test-Driven Development (ATDD) and Test-Driven Development (TDD).   Here’s a short description of their similarities, their differences, and their relationship.   

Let’s start with their similarities.   They both have three words in common (1).   They both are aimed at creating a quality system.   They involve writing things called tests, but which act as precise specifications on the behavior of either the system as a whole (ATDD) or a component or class of the system (TDD).   The tests are written before implementation starts, so sometimes they are referred to as “Test First”.

Now for their differences. ATDD is a communication process between the customer, developer, and tester to ensure that the requirements are well-defined. The acceptance tests created during the ATDD process should be understandable by the customer.   They represent the desired behavior of the system in an implementation-independent manner.   ATDD does not require test automation. However, usually the acceptance tests are automated for regression testing.   Acceptance tests do not change unless the requirements change.

TDD is a developer’s tool to help create well-written units of code that correctly performs a set of operations. The tests are implementation dependent. The TDD process requires automation. The tests are created one-by-one and the underlying code is revised to pass the new test.   All previous tests need to be run in order to ensure that revisions do not break them.   As a design is altered , the TDD tests will change to reflect the new design.

There is a relationship between ATDD and TDD.   Tests used in TDD can often be derived from ATDD tests in many applications. The design process determines which code units (classes or components) interact together to pass an acceptance tests and then determines the TDD tests for those code units.

ATDD may have an effect on code design. Names used in the acceptance test may be used in the code, thus providing a way to track things in a consistent manner.   Acceptance tests for business rule tests may be used as unit tests for methods which implement those business rules.

An example may clarify the relationship. Let’s take two acceptance test examples from a simple situation:

Scenario: Take a Bottle

Given 99 bottles

When a user takes a bottle

Then there are 98 bottles

Scenario: Add a Bottle

Given 2 bottles

When a user adds a bottle

Then there are 3 bottles

In conjunction with these tests, the triad (business representative, developer, tester) also determines what responses the system will have when the last bottle is removed; and what response it should have if there is a maximum number of bottles (e.g. 99) and that maximum is reached.

Designing a system takes these external acceptance tests and turns them into internal class or component tests.   The design process determines which class or component keeps track of the number of bottles; which one is responsible for handling invalid input such as adding a negative number of bottles; and how these classes and components interface with each other.

There are many applications where the acceptance tests just specify the external behavior.   For example, for a program that solves a Sudoku puzzle, the outline of acceptance test is easy to specify. Given a puzzle, does the program create a solution that matches the Sudoku requirements? A specific acceptance test has a puzzle as the input and the solution as the expected output.   Designing how a system actually solves the puzzle is not directly derivable from the acceptance tests. The TDD tests help with designing the algorithm contained within a quality solution.

In another application, the business says that a GPS unit must provide location information that is within ten feet of the actual location.   For an acceptance test, a spot is chosen and its location (latitude, longitude, altitude) is determined via independent means, e.g. surveying.   The GPS unit is put in that spot and the location it reports is compared to the surveyed location.   If the two are within ten feet, then the test passes.   This acceptance test does not help in designing how the GPS unit will work, only that it works as desired.

There is one more issue that can confuse the difference between ATDD and TDD. Automation of acceptance tests is usually performed in an acceptance test framework (Fit, Cucumber, etc.). A TDD test is almost always automated in a unit testing framework (e.g. Junit, Nunit).   However acceptance tests are sometimes automated in a unit testing framework.   This automation does tie them to an implementation, so they become more like unit tests.

(1) ATDD has at least two other slight variations – Behavior Driven Development (BDD) and Specification by Example (SPE). Note that the former has two words in common with TDD and the latter has none.