Test doubles: dummies, stubs, mocks, fakes
Tags: testing, dummy, fake, mock
Published: 2021-01-02 16:26:54

---
title: Test doubles: dummies, stubs, mocks, fakes
published: true
date: 2021-01-02 16:19:52 UTC
tags: Testing,dummy,fake,mock
canonical_url: https://le0nidas.gr/2021/01/02/test-doubles-dummies-stubs-mocks-fakes/
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/mynepe9ih45wa3cvato9.png
---

While testing we tend to replace some of the unit’s collaborators with _mocks_ as it is accustomed to call them. The problem with that name is that it is not accurate. The real name of those mocks is `test doubles` and there are four of them with mock being one of the types.

One reason for this misnaming is the wide usage of mocking frameworks that do not separate the types between them (I am looking at you [mockito](https://site.mockito.org/)).

So, lets try to define the four types and see when it is best to use them. We will be using a made up browser and its history and will not use any framework. Just theory:

{% gist https://gist.github.com/le0nidas/096c9cc9065a226768072eece1df50c7 %}

#### Dummies

A `dummy` is the test double that we use whenever we know that the collaborator will not be used:

{% gist https://gist.github.com/le0nidas/0117f31df4c1e504d928e49310b8eb5e %}

For example in the tests above we just need to check the browser’s active URL. We know that this does not evolve the browser’s history so we pass a collaborator that does nothing on every method call.

#### Stubs

A `stub` is the test double that we use whenever the collaborator is being used to query values:

{% gist https://gist.github.com/le0nidas/9e567056de072add361ae065daab5ee9 %}

For example in the test above we feed the browser with a pre-populated history since we know that the browser will need to peek for the last visited URL.

#### Mocks

A `mock` is the test double that we use whenever the collaborator is being used to perform an action:

{% gist https://gist.github.com/le0nidas/cfcd5fd13108292f4146434becec9991 %}

For example in the test above we need to make sure that the browser saves the provided URL to its history so we use a collaborator that can verify this behavior.

#### Fakes

A `fake` is the test double that we use whenever we need the collaborator to provide us a usable business logic:

{% gist https://gist.github.com/le0nidas/d6f148a451e4f030a21bfb3331db22fe %}

For example in the test above we need a history instance that works as expected (a simple stack) but without the hassle of having a database or using the file system.

#### Final thoughts

Having your own test doubles per case makes the code simpler and more readable but does that mean that we should remove our mocking frameworks? In my opinion no. Having a framework saves you a lot of time and keeps things consistent, especially in big projects with lots of developers.

Knowing the theory behind something is always good since it lays a common foundation for discussions and decisions. A mix of the two, framework and theory, could be achieved and help the test code in readability.  
For example, we can keep using [Mockito’s mock](https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#mock-java.lang.Class-) but name the variable `stubBlahBlah` if is used as a stub. This way the reader will know what to expect.

PS #1: [Spock](http://spockframework.org/) testing framework, besides being a great tool, provides a way to separate stubs from mocks not just in semantics but in usage too (ex: you cannot verify something when using a stub)

PS #2: There is another type of test double called `Spy` which is a toned down mock that helps in keeping state when a certain behavior takes place but does not verify it.