Acceptance Test Driven Development

I’m blogging the conference Agile Approaches for Delivering Business Value

Acceptance Test Driven Development

David Peterson

Summary

  • What happens if you put acceptance tests in the

    driving seat?

  • Fresh ideas about the agile development process

  • Practical techniques to improve your project’s agility

  • Emphasis on process and practice (non-technical)

Notes

Whilst working at EasyNet, David modified their normal XP iteration cycle to insert a phase where, for each story, acceptance test criteria were agreed and documented. Alongside this their testing harnesses were adapted to provide autoamted testing of acceptance tests wherever possible.

A key enabler was to separate out test case definition (which depends on the business requirement) from test scripting (which is dependent on, and coupled with, the system under test).

The technique adopted was to build test fixtures which interfaced between the (HTML) test cases and the system under test. This way the test cases can stay unchanged whilst the system changes. If the system changes in a way that breaks the test fixture that shows up as broken acceptance tests.

The tool is released as Concordion. Good write up on that site.

Update: See this post from Keith Braithwaite

Avatar
Julian Elve
Proactive application of technology to business

My interests include technology, personal knowledge management, social change

Next
Previous
comments powered by Disqus