Chapter 10: User Stories and Acceptance Tests

Overview

Code Together

(Sing to the tune of Come Together by The Beatles)

You got no requirements
You got no schedules
You got pair programmers
You got lots of Pepsi
You got goal donors tellin you stories
One thing I can tell you is you can t code in threes
Code together
Right now
With XP

You got ree-factoring
You got unit testing
You got tasty snack food
You got no documentation
You got index cards up to your knees
Go ahead and change that cause you know change is free
Code together
Right now

With XP

GROUCHO  

XP prefers that requirements be documented in terms of executable acceptance tests. XP prefers that design be documented by the code. ^[1]
”Robert C. Martin

If you lose a card, and if the customer does not detect that loss, then the card wasn t very important. If, however, at an interaction planning meeting, the customer says: ˜Hay [sic], where s that card about blah, blah, blah , you ll find it easy to recreate. ^[2]
”Robert C. Martin

User stories are, by their nature, transitory artifacts. They contain very little detail. The true tests of inclusion of a requirement in the production code are the acceptance tests (an automated method of proving with code that each user story has been implemented).

The stories themselves are simply placeholders ”promises for future conversations with the on-site customer. That is to say, they really don t contain a lot of detail ( generally just one or two brief sentences). They are memory joggers and a lightweight tool to help with the planning game rather than a specification.

In this chapter we look at user stories and acceptance tests together, because they re really two sides of the same coin.

Round and Round the Story Goes

On the OTUG discussion forum, Robert C. Martin wrote the following:

Light Bulb  

XP prefers that requirements be documented in terms of executable acceptance tests. XP prefers that design be documented by the code. ^[3]

So the code is the design and the tests are the analysis. Therefore, because you re coding and testing the whole time, you are by definition doing analysis and design all along. Circular, but brilliant nonetheless.

 

SATIRE WARNING

Perhaps XP doesn t go far enough. Catchy slogans and circular reasoning could be used to sell pretty much anything. Here are some we prepared earlier:

• The Java bytecode IS the requirements. Note that they are both concise and executable!

• The debugger IS the documentation. Who needs anything else? All clients should know how to use the debugger.

• Do Software Quality Assurance by Smelling the Code. Oops, that one isn t ours ”can t take credit for it.

• Rip-up, re-write, re-code, re-test, re-factor, realize its a rat s nest, resign. Kind of catchy, isn t it?

 

^[1] Robert C. Martin posting to OTUG ( http://www.rational.com), subject: <<include>> or <<extend>> ˜Just Say No , October 5, 2000.

^[2] Robert C. Martin posting to the newsgroup comp.software.extreme-programming, subject: The Case against XP, January 31, 2002.

^[3] Robert C. Martin posting to OTUG, op. cit.