DEV Community

Michal Lipski
Michal Lipski

Posted on

Test Doubles - Fakes, Mocks and Stubs.

This text was originally posted at Pragmatists blog

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.

Fake

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.

fake

@Profile("transient")
public class FakeAccountRepository implements AccountRepository {

   Map<User, Account> accounts = new HashMap<>();

   public FakeAccountRepository() {
       this.accounts.put(new User("john@bmail.com"), new UserAccount());
       this.accounts.put(new User("boby@bmail.com"), new AdminAccount());
   }

   String getPasswordHash(User user) {
       return accounts.get(user).getPasswordHash();
   }
}
Enter fullscreen mode Exit fullscreen mode

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.

stub

public class GradesService {

   private final Gradebook gradebook;

   public GradesService(Gradebook gradebook) {
       this.gradebook = gradebook;
   }

   Double averageGrades(Student student) {
       return average(gradebook.gradesFor(student));
   }
}

Enter fullscreen mode Exit fullscreen mode

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.

public class GradesServiceTest {

   private Student student;
   private Gradebook gradebook;

   @Before
   public void setUp() throws Exception {
       gradebook = mock(Gradebook.class);
       student = new Student();
   }

   @Test
   public void calculates_grades_average_for_student() {
       when(gradebook.gradesFor(student)).thenReturn(grades(8, 6, 10)); //stubbing gradebook

       double averageGrades = new GradesService(gradebook).averageGrades(student);

       assertThat(averageGrades).isEqualTo(8.0);
   }
}
Enter fullscreen mode Exit fullscreen mode

Command Query Separation

Methods that return some result and do not change the state of the system, are called Query. Method avarangeGrades, that returns average of student grades is a good example: Double getAverageGrades(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 sent. 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:

mock

public class SecurityCentral {

   private final Window window;
   private final Door door;

   public SecurityCentral(Window window, Door door) {
       this.window = window;
       this.door = door;
   }

   void securityOn() {
       window.close();
       door.close();
   }
}
Enter fullscreen mode Exit fullscreen mode

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.

public class SecurityCentralTest {

   Window windowMock = mock(Window.class);
   Door doorMock = mock(Door.class);

   @Test
   public void enabling_security_locks_windows_and_doors() {
       SecurityCentral securityCentral = new SecurityCentral(windowMock, doorMock);

       securityCentral.securityOn();

       verify(doorMock).close();
       verify(windowMock).close();
   }
}

Enter fullscreen mode Exit fullscreen mode

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

You liked this article

You can find more articles on TDD and testing on Pragmatists blog

Top comments (6)

Collapse
 
ben profile image
Ben Halpern

I love the graphics. Really well-explained, Michal.

Collapse
 
mrcosta profile image
Mateus Costa

Perfect. Very clean explanation.
I would just add that regarding this part of the code:

when(gradebook.gradesFor(student)).thenReturn(grades(8, 6, 10));

The first part:

when(gradebook.gradesFor(student)) is also a mock. Because if the method gradesFor is called with another parameter, will never return what we expected.

You are not explicit doing a mock as when using "verify", but is still mock.

Collapse
 
mrlarson2007 profile image
Michael Larson

Love this article! Nice way of defining theses concepts.

Collapse
 
alisneaky profile image
Ali Sadreddini

Definitely an easy to follow article to refer to when people are talking about the topic and misusing the terms. And the graphics are awesome

Collapse
 
pierreroth64 profile image
Peio Roth

Short and clear. Thanks.

Collapse
 
thdaraujo profile image
Thiago Araujo

Nice article. Where did you create the diagrams? They're cool.