Chapter 5. Mocks, Stubs, Test Spies
Creation of test doubles using static mock() method. At this point they do not differ from each other (except for the type they are pretending to be).
Creation of the SUT. No mock() method here, we want to test the real one! Dependency injection of DOCs into the SUT.
Stubbing of DOCs in order to satisfy the SUT (have a look at the Messenger class to understand what is required of each DOC).
Execution of the SUT method.
Verification of the behaviour of the SUT: "was the send() method invoked on mailServer DOC with the same CLIENT_EMAIL and MSG_CONTENT that were obtained from other collaborators?".
5.4. Example: TDD with Test Doubles
Let us now discuss an example which integrates two techniques we have already learned: TDD and test doubles.
This example shows how we can test and implement a service whose role is to inform interested parties about the results of races. The idea of the implementation is pretty obvious. There is a notification service, which allows clients to subscribe. The service should send out messages to all of its subscribers. And, basically, that is it.
In general, it is a good thing to avoid tight coupling between components of the system. In line with this rule, we want to make sure that the subscribers know as little as possible about the service, and vice versa. To achieve this result, we can use a publish/subscribe design pattern7 which does exactly this: it decouples publisher(s) from subscribers.
First, let us discuss some requirements for our class - RaceResultsService:
•It should allow clients to subscribe (which means they start receiving messages),
•It should allow subscribers to unsubscribe (which means they stop receiving messages),
•Every time a new message comes, it should be sent to all subscribers.
These simple requirements, along with some common sense, already furnish us with a lot of test cases. In the ensuing sections we will be implementing the following:
•If the client is not subscribed, it should not receive any messages,
•If client is subscribed, it should receive each incoming message once (and only once),
•If multiple clients are subscribed, each of them should receive each incoming message,
•Consecutive subscribe requests issued by the same client will be ignored (nothing happens),
•If the client unsubscribes, then it should be the case that no more messages are sent to it.
We shall test RaceResultsService (the SUT) and make sure it sends messages to the right subscribers (DOCs). At first glance, it seems like we must have at least three types to implement the discussed
7See http://en.wikipedia.org/wiki/Publish/subscribe.
78
Chapter 5. Mocks, Stubs, Test Spies
functionality. First of all, we have to have an object of class RaceResultsService (our SUT). Then, we must create a Client type which can subscribe, unsubscribe and receive messages (objects of this type will play the role of DOCs). We will also need a Message type, which will be being passed from the race results service to subscribed clients.
We will follow the TDD approach to implementing this functionality. Along the way we will also learn a thing or two about Mockito.
5.4.1. First Test: Single Subscriber Receives
Message
The first test is meant to verify whether, if a single client has subscribed to the RaceResultsService, it receives messages.
This test also plays another important role, as writing it helps us to set everything in its proper place. Before we do any real testing, writing some test code will allow us to come up with the basic structure of RaceResultsService and the interfaces of the DOCs. In fact, it will be some time before we are actually able to test anything.
We begin our test with the creation of the SUT, as displayed below.
Listing 5.17. Creation of an SUT
public class RaceResultsServiceTest {
@Test
public void subscribedClientShouldReceiveMessage() { RaceResultsService raceResults = new RaceResultsService();
}
}
This simple test code results in the RaceResultsService class being (auto)generated by the IDE, as shown in Listing 5.18.
Listing 5.18. The RaceResultsService class autogenerated by IDE
public class RaceResultsService {
}
To test the functionality under consideration, we must introduce the two remaining types: Client and Message. Listing 5.19 shows this next step – creating the DOCs.
Listing 5.19. Creation of DOCs
public class RaceResultsServiceTest {
@Test
public void subscribedClientShouldReceiveMessage() { RaceResultsService raceResults = new RaceResultsService(); Client client = mock(Client.class); 
Message message = mock(Message.class);
}
}
79
Chapter 5. Mocks, Stubs, Test Spies
Test doubles of client and message are both created using the Mockito.mock() method. At this point, their role is not yet defined - they could become dummies, stubs or test spies.
At this juncture the IDE complains that Message and Client types do not exist yet, and suggests creating both types. The question is, should they be created as interfaces or as classes? Following the basic rule of "code to an interface, and not to a implementation" ([gof1994]), I would choose the first option. This results in the creation of two empty interfaces – as shown in Listing 5.20.
Listing 5.20. Empty Client and Message interfaces
public interface Client {
}
public interface Message {
}
Now it is time to write the actual test. I would like it to present the following functionality:
•the client subscribes to the service,
•the service sends a message to the subscribed client.
This test is displayed in Listing 5.21.
Listing 5.21. Test: messages sent to a single subscribed client
public class RaceResultsServiceTest {
@Test
public void subscribedClientShouldReceiveMessage() { RaceResultsService raceResults = new RaceResultsService(); Client client = mock(Client.class);
Message message = mock(Message.class);
raceResults.addSubscriber(client); raceResults.send(message); 
verify(client).receive(message);
}
}
the client subscribes to the service,
the race results service sends a message (to all subscribers),
verification part: making sure that the subscribed client has received the message.
The verification part here clearly indicates that the client test double is a test spy. Its behaviour is verified after the execution of the tested code. Another test double - message object - is a dummy. Its behaviour is not verified, and the SUT does not require message to return any information. It is only being passed between other objects.
Once again, the code does not yet compile. Use IDE help to generate the required methods. You will end up with the following empty implementations of the RaceResultsService and Client types (Listing 5.22).
80
Chapter 5. Mocks, Stubs, Test Spies
Listing 5.22. Empty implementation of methods required for the first test
public interface Client {
void receive(Message message);
}
public class RaceResultsService {
public void addSubscriber(Client client) {
}
public void send(Message message) {
}
}
The test compiles, so let us run it. The error message – as shown in Listing 5.23 - clearly indicates that the functionality does not work. The client has not received any message.
Listing 5.23. The first test has failed: the client has not received any message
Wanted but not invoked: client.receive(
Mock for Message, hashCode: 20474136
);
-> at com.practicalunittesting.chp05.raceresults.RaceResultsServiceFirstTest
.subscribedClientShouldReceiveMessage(RaceResultsServiceFirstTest.java:25) Actually, there were zero interactions with this mock.
Very good! This means we really are into the red phase of TDD. Following the TDD approach, let us implement "the simplest thing that works" (see Section 4.2.2) that satisfies the failing test. Listing 5.24 shows such an implementation.
Listing 5.24. The first test has passed: a single subscriber receives a message
public class RaceResultsService {
private Client client;
public void addSubscriber(Client client) { this.client = client;
}
public void send(Message message) { client.receive(message);
}
}
Once again, even though I can imagine this code being changed, and can even suspect how it would be changed (e.g. using a collection of clients instead of a single client field), I do not make use of this knowledge. Coding it now would be an example of YAGNI. What I really need to do is make the test pass (move in small steps, remember?). And the implementation shown in Listing 5.24 achieves this goal. So, for the time being it counts as perfect and does not call for any changes.
The execution of the test assures me that this implementation will be good enough for now.
Before implementing the next test, I spend a bit of time refactoring and making the code more readable. In the case of the code written so far, there is not much to be done. The classes and interfaces are very short (no copied code fragments, etc.), and I like the current method and class names. At this point
81