concept stub in category software development

This is an excerpt from Manning's book Test Driven: Practical TDD and Acceptance TDD for Java Developers. Login to get full access to this book.

Table 4.1. Categorization of different types of mock objects

Type of mock	Description
Stubs	Stubs are essentially the simplest possible implementation of a given interface you can think of. For example, stubs’ methods typically return hardcoded, meaningless values.
Fakes	Fakes are a degree more sophisticated than stubs in that they can be considered an alternative implementation of the interface. In other words, a fake looks like a duck and walks like a duck even though it isn’t a real duck. In contrast, a stub only looks like a duck.
Mocks	Mocks can be considered even more sophisticated in terms of their implementation, because they incorporate assertions for verifying expected collaboration with other objects during a test. Depending on the implementation of a mock, it can be set up either to return hardcoded values or to provide a fake implementation of the logic. Mocks are typically generated dynamically with frameworks and libraries, such as EasyMock, but they can also be implemented by hand.

As mentioned, this is just one way to define the terms stub, fake, and mock, and I’m sure you will encounter other, partly conflicting definitions. One source for such definitions is Gerard Meszaros’ website, xunitpatterns.com (see “Test Double Patterns”). From here on, however, I will be using the terms mock and test double rather liberally to refer to using any of the three types of test doubles described previously, unless it the type is significant in the particular context I am talking about.

The definitions of stubs and fakes are straightforward, really—they’re just alternative implementations for a given interface or class. The third category of test doubles, however, requires more elaboration. Maybe we should take a look at mock objects in action to understand what that gibberish in table 4.1 means in practice.

Sometimes a stub is our only option

Some situations remain where the stub is our only viable option, however. For example, some teams developing embedded or highly hardware-dependent software can be constrained because the sheer cost of a particular hardware chip or device is prohibitive. Another perhaps more common scenario is one where the constrained hardware is available infrequently and only for short periods of time. In situations like that, it’s often better to run your acceptance tests on top of a simulator instead of only being available to run your tests for three hours every two weeks.