What are TDD and ATDD?

In this article, we highlight the similarities and differences between two popular testing methods commonly known as TDD and ATDD.

TDD stands for test-driven development, while ATDD stands for acceptance test-driven development. Understanding how these two testing approaches work is critical for testing professionals and this post will be a primer to get you started on your discovery of both. You will understand TDD vs ATDD.

What is Test-Driven Development (TDD)?

TDD is a system of developing software following Extreme Programming (XP) principles, however over time it spun off as an independent software development technique.

In TDD, unit testing is carried out on the source code directly.

First, the tester writes an automated test case which defines the desired function that the system should  ideally perform, but purposely designs the test case in such a way that it cannot be fulfilled by the system in its present state.

Secondly, the developer will take notes of the reasons why the system did not satisfy the test and writes out the code needed to refactor the system and enable it to pass it in the second try. This process is summarised in the graphic below.

The TDD process continues in this manner, zigzagging between failure and success, such that every iteration pushes the system the to its limits and then helps it overcome it through the feedback that is generated.

The TDD is an experiment in voluntary failure and it takes quite some courage to wrap your head around this counter-intuitive technique. However, once you do, you’ll be rewarded with a simple yet highly effective method to combat fear of failure during testing while improving on the work you do.

What is Acceptance Test-Driven Development (ATDD)?

ATDD is a collaborative method of testing which forces all the people involved in the creation of new software (e.g. testers, developers and users) to define as a team the acceptance criteria that the system has to fulfil in the early stages of development.

The point of this step is to ensure that all these stakeholders agree on the main goals of the project, especially in terms of the functionality that the end-user can expect. During this phase of ATDD, techniques like user personas and user stories can be very helpful.

When the acceptance tests are finally run on the system, failures are noted and the developers will then refactor faulty components by writing the code needed to satisfy the acceptance criteria at the next try.

This process is carried out iteratively, usually at the end of each sprint, until the final product is ready for deployment. The graphic below explains this.

ATDD provides the team with a clearer vision of how the end-product will work, allowing everyone to stay focused on the long-term goals rather than become lost in individual lines of code.

In summary

Now you have a good grasp of the basic differences between TDD and ATDD. These two testing methods are closely related, however ATDD also includes acceptance testing in the process and places more importance on team collaboration than TDD.

Both approaches fit in nicely with agile principles since both encourage the collection of feedback to build upon your earlier mistakes. As you continually refactor the system and address the issues you faced in the preceding try, these methods help you develop a more valuable final product in an incremental manner.