In this chapter we illustrated how to drive unit tests from a software
design, identifying test scenarios in a systematic way that ensures the
code is covered in all the right places. We also illustrated the use of
"stunt services" and mock objects to isolate the code being tested;
finally, we discussed driving unit tests deeper into algorithmic code
that may benefit from finer-grained testing. Is there a way to get 95%
of the benefit of the comprehensive unit testing we did in this chapter
with significantly fewer tests? In the next chapter, we'll show how to
do exactly that with controller tests. As you'll see, unit tests do have
their place, but controller tests can often represent a smarter, more
structured approach to application testing. 136 C H A P T E R 6 ? ? ?
Conceptual Design and Controller Testing As you saw in Chapter 5, unit
testing doesn't have to involve exhaustively covering every single line
of code, or even every single method, with tests. There's a law of
diminishing returns--and increasing difficulty--as you push the code
coverage percentile ever higher. By taking a step back and looking at
the design on a broader scale, it's possible to pick out the key areas
of code that act as input/output junctures, and focus the tests on those
areas.
