Marcano on acceptance-test-driven development

When I met Antony Marcano, who runs the essential blog Testing Reflections, a year ago at STARWest in Anaheim, I immediately liked his views on agile testing. He published a very insightful article in Better Software this month on a topic that's been top-of-mind for me recently: Acceptance-Test-Driven Development (ATDD). I'll let him explain (emphases mine):

ATDD bridges the gap between an idea summarized in a user story and the implementation of that story. It helps elicit the detail behind the idea to make it better understood by both the customer with the idea and the cross-functional development team that will implement it. ...

Whenever we begin to discuss acceptance criteria, it’s safe to say the user story alone is not enough. To establish a shared understanding of a user story, the customer elaborates on the idea behind it by first outlining some acceptance criteria—often in terms of the new behaviors that the system will exhibit once the story is implemented. This is so that the team has a high-level view of the story’s real meaning. Programmers, testers, and the customer exchange examples of specific inputs and outputs that further clarify the scope of the user story. This results in refinements to existing acceptance criteria or additional criteria. During the iteration, programmers and testers work with the customer to draw out the detail required for them to expand outlined acceptance criteria into specific examples in the form of tests. From these tests, programmers infer the underlying rules that must be implemented. During this process, with the help of a variety of testing techniques, testers help to identify exception cases and reduce other example behaviors into equivalent cases. The result is a set of examples, expressed as automated acceptance tests. These tests are run and, since the feature isn’t implemented yet, they fail—as expected. For each of these automated acceptance tests, programmers implement enough of the software for the acceptance test to pass (ideally using TDD with unit tests). Once all the acceptance tests for a story pass, the story is done— almost.

(He goes on to note that the story's not "done" until exploratory testing -- another important practice -- happens.) It seems to me that ATDD goes a long way to solving many pains: knowing when "done" is, eliciting requirements, developing the right features first, etc.