An Overview of TDD (Test Driven Development) & ATDD (Acceptance Test Driven Development)

Testers sure love acronyms.

And software testing is a veritable alphabet soup, where acronyms get thrown about with gusto by the professionals who work in the field.

In this article we zoom in on two of the most popular, TDD and ATDD, which stand for ‘test-driven development’ and ‘acceptance test-driven development’ respectively.

We’ll stretch out these acronyms like an accordion and make sure that by the end of this article, you know exactly what they refer to and the main differences between the two approaches.

Let’s get the music started.

TDD – Test-Driven Development

The first double-D acronym is method of software development which was first introduced by the XP brigade, but has generated sufficient interest to branch out into an independent development methodology.

In TDD, unit testing is conducted directly on the source code. An automated test case which defines the desired function that the system should perform is first written but — and here’s the twist — it is deliberately designed to be failed by the system in its current state.

The developer would then take stock of the reasons why the system failed and write out the minimum code necessary to refactor the system and make it pass the test.

A practical example: If the purpose of the code is to store a new customer in the database, the automated test would probably search the database for the new customer entered. Since the store to database feature is not yet implemented, the test will fail. The developer adds code to store to database and the test passes.

The process continues iteratively and each time a new test case is written which stretches the system further (but always to an inevitable failure) and hence yielding practical feedback about the improvements that are necessary.

If TDD had a motto it would be: The harder I fail, the stronger I get.

It is a conscious experiment in failing and an exceptionally simple, yet effective, design which runs counter to the tester’s intuitions but is able to inspire real confidence in removing the fear of failing.

A good sports analogy for TDD would be the high jump.

An athlete would set the bar slightly higher than his or her capabilities. Knowing full well that they will fail the attempt actually lifts off performance anxiety and helps them to carry out the jump in a calm state.

They would then review a video recording of the failed jump with their coach, who would be able to point out the necessary changes to their existing technique and timing, which they would then implement in order to successfully clear the jump next time.

ATDD – Acceptance Test-Driven Development

ATDD takes TDD a step further and adds an ‘A’.

Joking apart, acceptance testing is all about collaboration.

ATDD is a social form of software development which requires members of a development team (including testers, developers and users) to fully understand the acceptance criteria that have to be fulfilled by the system early on in the development process.

This ensures that all stakeholders understand the main objectives of each requirement in terms of the functionality it provides to the end-user. The acceptance criteria are often developed from a user’s perspective and in this case user personas and user stories can come in handy.

In ATDD, acceptance criteria for each requirement are written before coding starts. These criteria are best described by business representatives such as the requirements analyst.

When the acceptance criteria are developed and run on the system, any failures are noted and the developers refactor those components by adding the minimum code needed to help them pass the test at the next attempt.

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

As you can see, ATDD is practically identical to TDD in the later stages, the main difference being that the actual testing is preceded by a joint effort between different team members to mutually agree upon the acceptance criteria to be fulfilled.

This gives further direction to the team and helps them keep in mind the bigger picture that is the ultimate purpose of the finished product, rather than be absorbed in the nitty-gritty of code tweaking.

The motto for ATDD would be: Show me where I need to be and I’ll get there eventually.

If we go back to the high jump analogy I mentioned earlier, the only difference would be that before setting up the bar, the athlete and coach would get together to review and discuss the national and world records in the disciple, and make those their main objectives for the training.

Conclusion

In this article I gave an overview of TDD and ATDD. Both testing approaches emphasise the need to test your product while it is still being formed and highly value the feedback you get from failing tests rather than passing them.

This feedback is used in both cases to refactor the system and apply the minimum changes necessary to pass the test the second time round.

Although closely related, the main differences between the two approaches is that ATDD also includes acceptance testing and puts more emphasis on collaboration between developers, testers and users.