Alice continued walking for a time, and was just in the midst of wondering whether she could use her Palm Pilot to get a map home from this curious place that she was lost in (or at least find a nice hotel room), when two soldiers, who looked strangely like index cards, approached her.
"Excuse me, Miss" said the first soldier, "but the Queen of Hearts demands to see how much code you have written."
Over the next few chapters, we'll illustrate how to use DDT, using the real-life example of a hotel search application for travel web site VResorts.com. Because testing tends to be a "backwards-looking" activity, providing feedback on something just created, we'll step backwards through the project. So Chapters 4, 5, and 6 cover the coding and design activities, or "developer's space," while Chapters 7 and 8 cover the analysis activities, or "customer's space."
Chapter 4 introduces the Mapplet project, and explores the ICONIX/DDT "best practices" that we recommend in order to give your project the best possible start. We discuss what to do on delivery of a staged release, to keep the project on track.
Chapter 5 shows how to write fine-grained, "white box" unit tests against the detailed design.
Chapter 6 explores broader-grained, "gray box" controller tests, which are based on a conceptual design.
Chapter 7 explores one half of acceptance testing, covering scenario tests that are based on the system's behavioral specification (use cases).
Chapter 8 walks through the other half of acceptance testing, business requirement tests—i.e., test scripts that are the corollary of the customer's requirements. As with scenario tests, these test scripts can be signed off by the customer and used by a team of testers.