StoryTest-Driven Development (STDD) Is an extreme programming practice. The basic premise is that before any code is written, a team takes a story (or rough idea of a requirement) and fleshes out that story by producing an executable "storytest." Opponents say that STDD is "cowboy coding," or "snake oil," or just "a hindrance to real work." Proponents argue that STDD produces the simplest system possible and is the wave of the future, the new frontier.
Everyone Gets A Say
With traditional acceptance testing, developers would create an entire system, declare it finished, and then submit it for acceptance testing. This mostly manual testing tended to get bogged down in paperwork and occurred so late in the development lifecycle that any mistakes were very expensive to fix. Even if the system met all of the stated requirements and passed through acceptance testing with flying colors, the customer, who hadn't seen the system since the requirements meeting, often was left feeling like he had not gotten what he wanted. STDD makes it possible to formalize the expectation of the customer into an executable and readable contract that programmers have to obey if they want to claim a working system.
"STDD gets the right people collaborating at the right time," says Joshua Kerievsky, XP coach and founder of Industrial Logic, Inc. STDD brings together the customer, developers, and testers before any code has been written. They collaborate to identify a specific piece of functionality, or "story," to be worked on. Customers and testers then specify criteria to validate that the story works and create an executable document that can be accessed by anyone on the team.
A Glimpse Of STDD In Action by Brian Marick
Storytests As Props For Conversation
In order to estimate a story, programmers have to understand what the business expert wants. They learn this through face-to-face conversation. The business expert describes the feature, explains why it’s useful, and gives examples, perhaps scribbling them on a whiteboard. The programmers ask questions, split the feature into constituent parts (smaller tasks), ask more questions about those tasks, and sometimes propose variations on the feature that might be simpler to implement.
Examples are particularly useful because they ground the conversation in something concrete and keep important details from being lost in abstract discussions and vague generalities. To illustrate, let's suppose a business has a rule that, for accounting purposes, all months are treated as having thirty days. (Some bonds are valued under a similar rule.) One of the stories might be "Implement the 30-day rule." The business expert might write something like this on the whiteboard:
1 April to 1 May is 30 (as normal)
1 Feb to 1 March is 30 (even though 28)
1 Jan to 1 Feb is 30 (really 31)
Questions should follow. A programmer or tester might ask if it's really true that the number of days from 1 January to both 1 February and 31 January is thirty. The business expert wouldanswer that it is. Then someone else might ask, "So, it's twenty-seven days from 1 February to 11:59 PM on 28 February, but the next minute it's thirty days?" The business expert might start to answer "Yes," only to be interrupted by someone saying, "Not if it's a leap year," which would lead to a discussion of the relevance of leap years, and then, perhaps, to whether time zones matter.
That discussion might well be cut short, because the point here is for the programmers to have enough information to estimate accurately, not for them to know every last detail.
Conversational Examples Become Storytests
Once the
