XPDAY - Richard Watt, David Leigh-Fellows - Acceptance Test Driven Development - Monday 1st December 2003

How does a coder know when they are done? The natural tendency for a developer is to continue to perfect a piece of code for long after it has attained an acceptable level. The Unit Test ascertains whether a unit of code works. A Functional Test is used to ascertain whether a group of units are working together to satisfy a desired function. But these are both simply testing that the code is working in a manner that the developer intended. The Acceptance Test asserts the conditions of acceptance set by the customer or designer. They are less concerned with finding imperfections in code as they are with identifying the result of an imperfection. Acceptance tests relate better to requirements or stories than they do to units or objects at code level.

Acceptance tests are a way for the developer to know when they're done. Where automating acceptance tests is achievable, this should be done. A developer can keep working until the testing application gives 'the green light'.

Acceptance tests should be written at the same time as stories are specified. This helps to set the goal posts for and aid in estimating particular functionality for all disciplines involved in the process of designing and building software.

Acceptance tests are hard for many reasons. The customer is involved in defining the test. They are not always adept at structuring such a test framework and will thus need guidance on this. Acceptance tests raise the level of quality assurance support required on the project team. Writing the tests are time consuming. Maintaining the tests is also time consuming and requires careful management and organisation to ensure this is as efficient a process as possible. Setting a common framework for testing can be difficult across multiple work streams. So, acceptance test driven development is not an easy road, however it is worthwhile as it ultimately saves time, eliminates waste and increases quality.

A typical chronology for an acceptance test driven framework would look like this:

1. Select candidate stories for iteration or development
   
2. Write the acceptance test skeleton for each
   
3. Sense check the candidate stories
   
4. Using the iteration planning workshop as a starting point:
   
   • A small multidisciplinary group takes a few stories aside
     
   • The group lists the subtasks associated with each story and then provides an estimate on how long this will take to do
     
   • The group then presents back the subtasks and estimate to the wider group for critique
   
   
5. Check story dependencies and estimates
   
6. Pick highest value group of stories
   
7. Agree stories for iteration
   

And there you have how Acceptance Tests should be integrated into an XP process.