Chapter 9. Defining High-Level Acceptance Tests

Our trip is well underway, we just made our first pit stop for a tank of gas and a veggie sub (aren't Subways great!), and we're back on the road. Other than a minor disagreement about whether to put on a CD of Tony Rice on guitar or Sergei Nakariakov on trumpet, it's all been smooth sailing (first Tony, then Sergei).

Now we're ready to think about acceptance tests. Acceptance tests put meat on the bones provided by user stories. We start defining these tests during the initial release or project planning sessions but don't expect to get into too much detail at this point. What you're primarily after right now is to identify a few basic things that illustrate that a story has been acceptably implemented: the "happy path." After the stories have been selected in iteration planning and during the iteration is the time to lead customers off the "happy path" and dig into handling errors, unexpected paths through the system, unusual or unexpected data, and so on.

You want to avoid doing more than you absolutely need to now, because the customer could change his mind and not choose these stories. But you need enough details to get accurate story estimates. As always, asking questions will help ensure that the acceptance tests are a true reflection of the customer's requirements.

Keep in mind that the unit tests and test-first design practices of an XP project cover many of the testing needs. Acceptance tests show the customer that the story is complete, but they don't have to exercise every line of code or every possible test case you can think of. Different projects need different levels of testing. Your customer will decide the minimum she feels comfortable with. If you don't need to use all our suggested techniques in your project, skip them. We're presenting you with a toolbox for your own road trip. If the box is too heavy to carry around on your project, leave out the tools you don't need.