Working on a few ExtremeProgramming and XpIsh? projects now, I have noticed a high degree of success in having AcceptanceTests defined and implemented before starting on a story. Here are some of the benefits I have seen:
- IterationPlanning meetings are simplified. They are discussed and broken down in terms of acceptance tests. Each task for a given story is an AcceptanceTest.
- TestFirstDesign is maintained. Developers don't have to guess on what classes they need to modify or what frameworks they need to develop. They (or preferably the customer) implement the test based on the test spec. Then they run the test to see what they need to do first. The developer uses the larger AcceptanceTest as a guide for what UnitTests he/she needs to write.
- Helps maintain DoTheSimplestThingThatCouldPossiblyWork. If the AcceptanceTests are not available, there is no concrete guide to tell the developer what to implement, so a lot of the time developers implement "stuff" that isn't necessarily needed. You see evidence of this a lot of times in iteration meetings, "I think we'll need to implement a thing-a-ma-bobber, so let's make it a task."
Of course, having the
AcceptanceTests up front can be pretty difficult, especially when working in an
XpWithoutCustomerBuyIn type of environment. Real-world factors such as resources, schedule, and customer buy in will affect it. But, I think that with a little dicipline on behalf of the developers and the customer, this is very attainable.
--JavidJamae
Acceptance Tests First