When to Use a Test Double -- Test-Driven Development for Embedded C (for Shrinivasan Mani) by James W. Grenning -- Free eBooks online Reading

When to Use a Test Double

Not all interactions will use test doubles. My rule of thumb is to use the real code when you can and use a test double when you must. You will need to use judgment to decide when to fake and when not to fake.

For example, if the CUT uses a linked list as one of its collaborators, there is no need to use a fake linked list. Use the real one. The test case consults the linked list during the verify stage of the Four-Phase Test pattern to see whether the right additions, deletions, and modifications were made to the linked list.

Here are some common reasons to use a test double:

Hardware independence: Having test doubles for hardware interactions will allow testing independently from the hardware. It also provides the ability to feed a wide variety of inputs into the core of the system that may be very difficult or time-consuming to do in the lab or field.
Inject difficult to produce input(s): Some computed or hardware-generated event scenarios may be difficult to produce. By adjusting the return result of a test double, the CUT might have all it needs to trigger some unlikely execution path.
Speed up a slow collaborator: If tests don’t run fast, you will likely stop running them as often as you should. A slow collaborator, such as a database, a network service, or some number crunching, can be faked out by returning a result controlled by the test case, speeding up the test.
Dependency on something volatile: The classic example of a volatile collaborator is the clock. You have some event that is supposed to happen at 8:42 a.m.—either you get one chance a day or you have to reset the clock. But with a double standing in for the clock, it can be 8:42 a.m.—or the last day of leap year—whenever you want.
Dependency on something under development: Design often encompasses unknown areas, especially when hardware and software are concurrently developed. As you approach an area of the unknown, develop a test double with the interface that best meets the CUT’s needs. Progress on the CUT can continue, while at the same time exploring the CUT’s needs of the currently unimplemented service.
Dependency on something that is difficult to configure: If a DOC is difficult to set up and get into one or more desired states, it may be best to substitute a test double. A database is a good example of a DOC that you could test with but is difficult to set up.

In Gerard’s book, he identifies different types of doubles. We’ll use spies, stubs, mocks, and exploding fakes in this book. It is good to know there are other kinds of doubles.

Name	Variation
Test dummy	Keeps the linker from rejecting your build. A dummy is a simple stub that is never called. It is provided to satisfy the complier, linker, or runtime dependency.
Test stub	Returns some value, as directed by the current test case.
Test spy	Captures the parameters passed from the CUT so the test can verify that the correct parameters have been passed to the CUT. The spy can also feed return values to the CUT just like a test stub.
Mock object	Verifies the functions called, the call order, and the parameters passed from the CUT to the DOC. It also is programmed to return specific values to the CUT. The mock object is usually dealing with a situation where multiple calls are made to it, and each call and response are potentially different.
Fake object	Provides a partial implementation for the replaced component. The fake usually has a simplified implementation when compared to the replaced implementation.
Exploding fake	Causes the test to fail if it is called.

These terms are helpful when talking about the different kinds of behavior and capability needed by the test double. Often a distinction is not needed, though, so I suggest you don’t get too hung up on the terms in practice. You will find that people generally use the terms fake, mock, and stub interchangeably.

Choosing to use test doubles for the CUT is not an all-or-nothing proposition. Most often you will have a variety of real and fake collaborators, as shown in Figure Using test doubles and real collaborators . Also, for some tests you will want to use the production code collaborator, and for others you will want the test double.

Figure 5. Using test doubles and real collaborators