"Let the developers consider a conceptual design," the King said, for about the twentieth time that day.

"No, no!" said the Queen. "Tests first—design afterwards."

"Stuff and nonsense!" said Alice loudly. "The idea of writing the tests first!"

"Hold your tongue!" said the Queen, turning purple. "How much code have you written recently, anyway?" she sneered.

"I won't," said the plucky little Alice. "Tests shouldn't drive design, design should drive testing. Tests should verify that your code works as it was designed, and that it meets the customer's requirements, too," she added, surprised by her own insight. "And when you drive your tests from a conceptual design, you can test smarter instead of harder."

This is a book about testing; not just QA-style visual inspection, but also automated testing—driving unit tests, controller tests, and scenario tests from your design and the customer's requirements. As such, there's bound to be some crossover between the techniques described in this book and what people set out to do with test-driven development (TDD). In some ways the two processes work well together, and we hope that test-driven software developers will gain from combining the best of both worlds. That said, there are also some fundamental differences, both in the practices and the ideas underpinning both disciplines.

Chapter 1 in this book provides a high-level overview of DDT. We also briefly introduce the Mapplet project that we'll be using later in the book to illustrate how to get the best from design-driven testing.

Chapters 2 and 3 go on to compare and contrast DDT and TDD. In Chapter 2 we run through what it's like to approach a project using TDD. By the end of the chapter we hope you're convinced that there must surely be a better way. And there is! We run through the same scenario again in Chapter 3, but this time using DDT. The results are far more satisfying.