Acceptance Test-Driven Development and Test-Driven Development - How They Are the Same and How They Are Different Revisited

January 16, 2015 — Posted by Ken Pugh

If you are interested in ATDD or TDD training go here.

 

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 specifications on the externally visible behavior of the system (ATDD) or on how that behavior is bound within 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 are usually not run until the entire implementation that supports them is built.  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. Tests depend on the public interface of the things they test. The TDD process almost always requires automation to be valuable, since the tests are run frequently.  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.  Analyzing TDD tests may suggest changes to the design of the classes and their responsibilities.  Some parts of 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 an answer that matches the Sudoku requirements? A specific acceptance test has a puzzle as the input and the answer as the expected output. Designing how a system actually solves the puzzle is not directly derivable from the acceptance tests. Someone needs to create or select an algorithm that solves the puzzle.  TDD tests can help create quality code when implementing the selected algorithm.

In another application, the business says that a GPS unit must provide location information that is within ten feet of the actual location. For one acceptance test, a set of spots are chosen and their location (latitude, longitude, altitude) is determined via independent means, e.g. surveying. The GPS unit is put in those spots and the locations it reports are compared to the surveyed locations. If the two are within ten feet in all cases, 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 and typically less readable by the customer. 

(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.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives (www.netobjectives.com). He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban