Acceptance Test Driven Development (ATDD) is an agile system development life cycle approach in which acceptance tests are defined early in the process prior to (and in some cases during) the system development process. Such acceptance tests act as both detailed requirements and test cases at the same time, thus delivering efficiency, increasing quality and producing a definitive set of acceptance criteria early on. ATDD can tremendously assist in preserving functional scope and focus while simplifying collaboration across the team. Test Driven Development (TDD) which is the developer-based view of this approach will not be discussed here.

How does it work?

The ATDD process typically starts with the team (customer, BAs, developers, testers…) writing a number of unambiguous test cases which describe what the function or feature are intended to receive as inputs and produce as outputs. As the number of test cases grows, more conditions are covered and the design of the product is further refined. Acceptance test cases are typically stored in a table and can be managed in an online web portal or Wiki. This enables all information to be viewed and updated by all the project participants and easily monitored by the target customer. Once the team feels a sufficient set of acceptance tests has been defined developers can start their work while automated testing scripts can start to be executed in parallel. That is done by running through the test cases table and feeding the test cases into the product using hooks (called “fixtures”) which have been imbedded in the code by the developers or the testers. This provides the team with a definitive indication of progress and quality in real-time while at the same time considerably reduces the effort of testing. It also creates an inherent regression testing library as part of the project at no significant added effort. Once all tests pass, an additional round of regression testing is done to assure that changes haven’t broken anything and the functions or features can be released. Iterations tend to be short and focused on a relatively small number of functions or features which allow for continues readjustment and reprioritization.

The Behavior-Driven Development variant:

A noteworthy variant of the ATDD process is the Behavior-Driven Development (BDD) process. While the core of BDD is very similar to ATDD, there is a great difference in the approach to the subject material. In ATDD, the tests are written from an engineering point of view, and have to be very technical. In BDD on the other hand, the tests are written in an almost natural language, and describe situations the customer would understand. The tests thus describe functionality in a more abstractisized fashion than in ATDD. This has a twofold benefit: firstly, the tests are much more readable, both for the developers and the customer; secondly, the tests are a lot more stable, since the abstract functionality of a system changes more rarely than the technical implementation thereof.

Tools of the Trade:

One of the tools most widely associated with ATDD is FitNesse. It is a holistic development tool, containing a wiki, a server, and an automated testing tool designed specifically for acceptance testing. It currently supports java and .NET technology. The fact that it is both wiki and automated testing tool gives rise to some very nice opportunities, since the tests themselves can be maintained in a wiki fashion. And since it is built with acceptance testing in mind, the tool supports extensive descriptions of the tests. BDD on the other hand, is more widely associated with Cucumber, a ruby-based tool that also supports java, flex, .NET, and web-based applications. Cucumber has a custom-built language that it takes as input (Gherkin), a language which is fine-tuned for user scenarios. Cucumber’s main feature is its ability to effortlessly borrow steps of one test for another, and to easily run selected groups of tests. The way it works is in three layers. The top layer is the test cases written in Gherkin, they are from a customer’s point of view and fairly static. The middle layer is the more detailed breakdown of the test steps, where the actual mechanics of the test is written out. The final layer consists of hooks built into the application itself that is written in the native language of the application, and is very technical. The amount of readability and stability versus technicality and detail increases as one goes further up in the layers, providing an easy way to keep the big picture in mind, and to have the customer involved without him needing extensive coding skills.

Key Benefits:

Definitive requirements reduce misunderstandings
Delivers efficiencies by taking care of requirements and test design as a single activity
Promotes collaboration in the team
Prevents project defocus (feature creep)
Thorough product testing
Enhances customer awareness and understanding of the product’s capabilities and limitations
Simplifies documentation development and maintenance
Enables earlier testing, then any other SDLC approaches, resulting in earlier defect detection
Automated regression testing is delivered as part of the project