Test Doubles

Today my mentor Rabea gave me an idea about a topic for a blog post: the test doubles.

Test doubles have entered my programming life in a mysterious way and have basically always stayed rather mysterious to me, so I thought it’s time I understand them a little better (and Rabea’s Zagaku of today actually helped a lot, so thanks Rabea!)

As I said, test doubles are something which were introduced to me quite at the beginning of my apprenticeship, and since then I’ve used them rather frequently for testing. But I’ve used them without really knowing all the different test double types: to me they were all doubles, and I was calling all of them like that.

But there are different test doubles, and they all have different names and uses. So let’s see some of the test doubles that you might use, and how they differ.

First of all,

They can come quite handy for your tests to become more easy to write when there is a lot of class coupling going on in your code base.

The most common types of test doubles are stubs, mocks, and fakes, but there are also dummies and spies.

In this blog post I’m going to write about three of them: dummy, stub and spy test doubles.

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists, when a parameter is needed for the tested method but without actually being used.

A dummy object can implement methods that return nothing, or in case of typed languages that return null .

Let’s see at the simple example below:

Animal class is instantiated with the Shelter class but for the purpose of the test above is it ok to instantiate it with a ShelterDummy class that implements the same interface as none of the methods that ShelterDummy implements are called in the test (so we don’t care about their outcomes.)

A stub object implements a required interface, but instead of missing method bodies it usually returns canned answers to calls made during the test.

Stubs can be used when you need an object to return specific values in order to get your code under test into a certain state.

In the example above (a Roman Numeral application in JavaFx) when a number is entered in a TextField and a Button is pressed, a Label is updated with the correspondent Roman number for the number entered.

A LabelStub sets a number which is hardcoded in the method setText() and the method getText() , which returns the Roman number for "44" , asserts that the addClickHandler() method actually worked and did set an action on the button.

Spies are stubs that also record some information based on how they were called. It could be used to ensure that a method was called by your system, or to count the number of invocations of a method.

In the example in JavaFx above, I want to test that an action is set to a Button. In my test I’m testing that when the method addClickHandler() in ActionSetter is called, the ButtonStub field wasClicked is assigned a value true. That would prove that the method setOnAction(), called in addClickHandler() method, was actually called.

Related posts:

How can I get my dog to quit jumping on random people as we walk? Are you in the same situation where your puppy jumps up at strangers when you go on walks? If your puppy is a young pup, jumping up…