2 What is a unit test?

As mentioned in chapter 1, there are a surprising number of nuances in the definition of a unit test. Those nuances are more important than you might think, so much so that the differences in interpreting those nuances have led to two distinct views on how to approach unit testing.

These views are known as the classical and the London schools of unit testing. The classical school is called "classical" because it’s how everyone originally approached unit testing and test-driven development. The London school takes root in the programming community in London.

The discussion in this chapter about the differences between the classical and London styles lays the foundation for chapter 5, where I cover the topic of mocks and test fragility in detail.

In this chapter, I compare unit and integration testing from the perspectives of the classical and London schools.

Let’s start by defining a unit test, with all due caveats and subtleties. This definition is the key to the difference between the classical and London schools.

2.1  The definition of "unit test"

There are a lot of definitions of a unit test. Stripped of their non-essential bits, the definitions all have the following three most important attributes.

A unit test is an automated test that

2.1.1  The isolation issue: the London take

2.1.2  The isolation issue: the classical take

2.2  The classical and London schools of unit testing

2.2.1  How the classical and London schools handle dependencies

2.3  Contrasting the classical and London schools of unit testing

2.3.1  Unit testing one class at a time

2.3.2  Unit testing a large graph of interconnected classes

2.3.3  Revealing the precise bug location

2.3.4  Other differences between the classical and London schools

2.4  Integration tests

2.4.1  End-to-end tests are a subset of integration tests

2.5  Summary