If we think of the interdependencies between objects in an application as a graph it becomes quickly apparent that there are a number of nodes that have dependencies on, not just one, but many other objects. Attempting to place an object with a lot of dependencies under test is challenging. Each of the dependent objects must be constructed and included in the test. When these dependencies interact with external resources such as the network or file system, the problem becomes intractable. Pretty soon we're testing the entire system at a time. This is a legitimate testing strategy, known as integration testing, but we're really just interested in ensuring that the functionality of a single class is correct.

Integration testing tends to be slower to execute than unit tests.

The subject of a test can have a large dependency graph that makes testing it difficult. You can see an example here:

We need to find a way to isolate the class under test so that we don't have to recreate all the dependencies, including the network. We can think of this approach as adding bulkheads to our code. We will insert bulkheads to stop tests from flowing over from one class to many. These bulkheads are similar to how oil tankers maintain separation to limit the impact of spills and maintain weight distribution as can be seen here:

*Image courtesy of http://www.reactivemanifesto.org/.

To this end we can use fake objects that have a limited set of functionalities in place of the real objects. We'll look at three different methods of creating fake objects.

The first is the, rather niftily named, test spy.