The Pros and Cons

The use of dummy and mock objects is not uncontested, both in the software tester community and in the XP world. We tried to collect the most important arguments from both camps. We begin with the benefits of dummy objects:

Mock objects are special dummy species, offering additional benefits:

All points listed above relate to either increase of independence (of tests and code) or improvement of communication. All these benefits are confronted with drawbacks:

Robert Binder estimates the effort involved in creating stubs as being very high [Binder99, p. 662]. In particular, the large number of stub objects needed to supply each single test with the required responses is a big obstacle in the general use of this technique, according to Binder. Our experience does not confirm this theory; we normally manage with one single and easily configurable mock object per test. This discrepancy in experiences results partly from differences between development by the test-first or test-after approach, where the latter is based on the classic testing theory. Moreover, conventional stubs often simulate the real behavior of a system, requiring a much higher implementation effort, compared to slim mock objects.

Brian Marick [00, p. 110] identified two major problems in the use of stubs: (1) We implement each misconception we have about the real object in the dummy object. (2) Errors we would otherwise have found through indirect invocation in the helper object slip through. Reason (2) warns us against the assumption that, when using the mock technique, interaction tests like the ones described in , , can be totally omitted; at best, their number reduces.

Heuristics for the Use of Mocks

Careful balancing between the large number of benefits and drawbacks takes a lot of experience and the courage to experiment. We use dummy and mock objects in the following situations:

Whenever we can write the test as easily and clearly with the same or less redundancy without dummy objects, then we will do without them. The more we get used to them, the more often we will find good reasons to use them. One reviewer pointed out that it's common to start using a stub class for unimplemented functionality that evolves into the real class later on. This kind of temporary dummy is found most often during the development of model code. However, we have to be careful to ensure that our mock objects do not get too complex. Signs of excessive complexity include:

In these cases, it makes sense to take a step back and ask ourselves whether we can simplify our mocks (e.g., by distributing them over several mock classes), whether we need them at all, whether a simple dummy class would do the trick, or whether the mock problem actually turns our attention to a design problem.