Automated Acceptance Tests

The idea of automated acceptance tests originates in eXtreme Programming^[3] (XP), specifically in the practice of Test-Driven Development^[4] (TDD).

Instead of a business stakeholder passing requirements to the development team without much opportunity for feedback, the developer and stakeholder collaborate to write automated tests that express the outcome that the stakeholder wants. We call them acceptance tests because they express what the software needs to do in order for the stakeholder to find it acceptable. The test fails at the time of writing, because no code has been written yet, but it captures what the stakeholder cares about and gives everyone a clear signal as to what it will take to be done.

These tests are different from unit tests, which are aimed at developers and help them to drive out and check their software designs. It’s sometimes said that unit tests ensure you build the thing right, while acceptance tests ensure you build the right thing.

Automated acceptance testing has been an established practice among good XP teams for years, but many less experienced agile teams seem to see TDD as being a programmer activity only. As Lisa Crispin and Janet Gregory point out in Agile Testing: A Practical Guide for Testers and Agile Teams [CG08], without the business-facing automated acceptance tests, it’s hard for the programmers to know which unit tests they need to write. Automated acceptance tests help your team to focus, ensuring the work you do each iteration is the most valuable thing you could possibly be doing. You’ll still make mistakes—but you’ll make a lot less of them—meaning you can go home on time and enjoy the rest of your life.