ATDD - What is this all about?

Acceptance Test Driven Development (ATDD)

Definition

Acceptance test driven development, or ATDD, is a collaborative practice wherein application developers, software users, and business analysts define automated acceptance criteria very early in the application development process.

In the ideal situation (though rarely attained in practice), the product owner, customer or domain expert is able to specify new functionality by writing new acceptance tests or test cases, without needing to consult developers.

Acceptance test driven development, or ATDD, is a collaborative practice wherein application developers, software users, and business analysts define automated acceptance criteria very early in the application development process.

Benefits/Advantages

Just as TDD results in applications designed to be easier to unit test, ATDD favors the creation of interfaces specific to functional testing.


Acceptance tests have several key advantages over lower-level tests:

• As a design framework prior to coding, they focus the developer on the user's needs. This is an important benefit. It is much easier to design functions correctly, when you can see them holistically, rather than the bottoms-up approach of TDD where the focus is on tiny steps developed within the scope of a single function.
• The developer validates the code at the level of the user experience. If the previous benefit was important, this one is crucial. It is entirely possible to write software that enjoys 100% code coverage, where every unit tests passes, but whose functionality is still broken. Even if the functionality is correct, the software still might not do what the user requested. In counterpoint, if the code is defined by acceptance tests, it is no longer possible to pass all the test and not work or not do what the user requested. Passing all acceptance tests (presuming they’re correctly written) guarantees satisfaction with user needs and validates the software.
• Acceptance tests document the software. This last point gets at what is one of the most pervasive misconceptions about unit tests: that they document the code. This is a canard that keeps being tossed about as a good reason for writing unit tests. It is, in a word, nonsense. If you’re looking at unit tests as documentation for the code, something upstream is seriously broken.

Tools

Fit/FitNess, HP's Quick Test Pro, Cucumber or others.