Chapter 5. Mocks, Stubs, Test Spies
5.4. Example: TDD with Test Doubles
5.4.1. First Test: Single Subscriber Receives
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 {
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).
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.
Chapter 5. Mocks, Stubs, Test Spies
I would only suggest writing some Javadocs: namely, for the RaceResultsService class, as this is the crucial part of the code (from the business point of view)8.