chapter four

4 The four pillars of a good unit test

 

This chapter covers:

  • Exploring dichotomies between aspects of a good unit test
  • Defining an ideal test
  • Understanding the Test Pyramid
  • Using black-box and white-box testing

Now we are getting to the heart of the matter. In chapter 1, you saw the properties of a good unit test suite:

  • It is integrated into the development cycle. You only get value from tests that you actively use; there’s no point in writing them otherwise.
  • It targets only the most important parts of your code base. Not all production code deserves equal attention. It’s important to differentiate the heart of the application (its domain model) from everything else. This topic is tackled in chapter 7.
  • It provides maximum value with minimum maintenance costs. To achieve this last attribute, you need to be able to

    • Recognize a valuable test (and, by extension, a test of low value)
    • Write a valuable test

As we discussed in chapter 1, recognizing a valuable test and writing a valuable test are two separate skills. The latter skill requires the former one, though; so, in this chapter, I’ll show how to recognize a valuable test. You’ll see a universal frame of reference with which you can analyze any test in the suite. We’ll then use this frame of reference to go over some popular unit testing concepts: the Test Pyramid and black-box versus white-box testing.

Buckle up: we are starting out.

4.1  Diving into the four pillars of a good unit test

4.1.1  The first pillar: Protection against regressions

4.1.2  The second pillar: Resistance to refactoring

4.1.3  What causes false positives?

4.1.4  Aim at the end result instead of implementation details

4.2  The intrinsic connection between the first two attributes

4.2.1  Maximizing test accuracy

4.2.2  The importance of false positives and false negatives: The dynamics

4.3  The third and fourth pillars: Fast feedback and maintainability

4.4  In search of an ideal test

4.4.1  Is it possible to create an ideal test?

4.4.2  Extreme case #1: End-to-end tests

4.4.3  Extreme case #2: Trivial tests

4.4.4  Extreme case #3: Brittle tests