In this chapter, we've learned about the structure of a well-written unit test. We've got to know how to use the four phases, that is setup, exercise, verify, and teardown, to map a single test to a certain component behavior. We've addressed the different techniques to set up a test fixture efficiently and illustrated the relation of a behavior to its verification.

Once we were familiar with how to write a test, we've been concerned with what to test. We've understood why we should always start testing with happy-path scenarios and do the corner cases later on. Moreover, we've been introduced to how code coverage can help detect holes in our safety net.

In the last section, we've discussed the pros and cons of the various test naming conventions. We've learned about the difficulties to map behavior verification into a meaningful name, and showed some possibilities to reduce a test name to the essentials.

The next chapter will evolve our example to make use of component dependencies...