Test Doubles — Fakes, Mocks and Stubs. (2024)

In automated testing it is common to use objects that look and behave like their production equivalents, but are actually simplified. This reduces complexity, allows to verify code independently from the rest of the system and sometimes it is even necessary to execute self validating tests at all. A Test Double is a generic term used for these objects.

Although test doubles come in many flavors (Gerard Meszaros introduced five types in this article), people tend to use term Mock to refer to different kinds of test doubles. Misunderstanding and mixing test doubles implementation may influence test design and increase fragility of tests, standing on our way to seamless refactorings.

In this article I will describe three implementation variations of testing doubles: Fake, Stub and Mock and give you examples when to use them.

Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code.

An example of this shortcut, can be an in-memory implementation of Data Access Object or Repository. This fake implementation will not engage database, but will use a simple collection to store data. This allows us to do integration test of services without starting up a database and performing time consuming requests.

Apart from testing, fake implementation can come handy for prototyping and spikes. We can quickly implement and run our system with in-memory store, deferring decisions about database design. Another example can be also a fake payment system, that will always return successful payments.

Stub

Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects.

An example can be an object that needs to grab some data from the database to respond to a method call. Instead of the real object, we introduced a stub and defined what data should be returned.

Instead of calling database from Gradebook store to get real students grades, we preconfigure stub with grades that will be returned. We define just enough data to test average calculation algorithm.

Command Query Separation

Methods that return some result and do not change the state of the system, are called Query. Method averageGrades, that returns average of student grades is a good example.
Double averageGrades(Student student);

It returns a value and is free of side effects. As we have seen in students grading example, for testing this type of method we use Stubs. We are replacing real functionality to provide values needed for method to perform its job. Then, values returned by the method can be used for assertions.

There is also another category of methods called Command. This is when a method performs some actions, that changes the system state, but we don’t expect any return value from it.
void sendReminderEmail(Student student);

A good practice is to divide an object's methods into those two separated categories.
This practice was named: Command Query separation by Bertrand Meyer in his book "Object Oriented Software Construction".

For testing Query type methods we should prefer use of Stubs as we can verify method’s return value. But what about Command type of methods, like method sending an e-mail? How to test them when they do not return any values? The answer is Mock - the last type of test dummy we gonna cover.

Mock

Mocks are objects that register calls they receive.
In test assertion we can verify on Mocks that all expected actions were performed.

We use mocks when we don’t want to invoke production code or when there is no easy way to verify, that intended code was executed. There is no return value and no easy way to check system state change. An example can be a functionality that calls e-mail sending service.
We don’t want to send e-mails each time we run a test. Moreover, it is not easy to verify in tests that a right email was send. Only thing we can do is to verify the outputs of the functionality that is exercised in our test. In other worlds, verify that e-mail sending service was called.

Similar case is presented in the following example:

We don’t want to close real doors to test that security method is working, right? Instead, we place door and window mocks objects in the test code.

After execution of securityOn method, window and door mocks recorded all interactions. This lets us verify that window and door objects were instructed to close themselves. That's all we need to test from SecurityCental perspective.

You may ask how can we tell if door and window will be closed for real if we use mock? The answer is that we can’t. But we don’t care about it. This is not responsibility of SecurityCentral. This is responsibility of Door and Window alone to close itself when they get proper signal. We can test it independently in different unit test.

Further Reading

Test Double - Martin Fowler
Test Double - xUnit Patterns
Mocks Aren't Stubs - Martin Fowler
Command Query Separation - Martin Fowler