The Queen left off, quite out of breath, and said to Alice: "Have you seen the Mock Object yet?"
"No," said Alice. "I don't even know what a Mock Object is."
"It's the thing Mock Object soup is made from," said the Queen.
"I never saw one, or heard of one," said Alice. "And I hardly think we should need one whilst integration testing."
What we've covered up until now we would consider the minimum that a team should do in order to really benefit from DDT. As with any discipline, you'll find that you get better at it the more you do, and you may well reach the point where you want to do more with the process. This final part is for those people who want to take DDT to the "next level." These final chapters are also unashamedly technical: non-programmers beware!
If you stop here, you'll have learned most of what you need to use DDT in the real world. But you will miss out on the horrors of the Temple of Doom (aka un-testable codebase) and its thoroughly scrubbed-up, wiped-down, and redesigned, fully testable alternative. Testing experts who want to earn their peeling, sun-faded "I studied to become a DDT guru and all I got was this lousy sticker!" sticker should, of course, read on.
Chapter 9 looks at the world from a unit-testing developer's point of view, faced with a code base that must have been written by some "test-unconscious" colleagues.
Chapter 10 presents the flipside of the untestable codebase, re-approaching it with a proper design and an eye towards unit testing.
Chapter 11 explores integration testing—tests that involve calls to external systems. These are a vital part of DDT (and any other development process), but we've moved them to the "Advanced" section since integration tests involve a thorny set of issues, and it makes sense to master DDT first before being confronted by them.
Chapter 12 goes microcosmic—sub-atomic, in fact—and looks at how to use DDT for algorithmic unit testing.