Chapter 5. Mocks, Stubs, Test Spies
Let us discuss our sample code (Listing 5.12) some more. The only indirect output of the SUT is its communication with the send() method of mailServer. This is something we can verify using test spy. Listing 5.15 shows how it can be done using Mockito’s verify() method, exactly as discussed in Section 5.1.3.
Listing 5.15. Taking control over indirect inputs
MailServer mailServer = mock(MailServer.class);
Messenger sut = new Messenger(mailServer, templateEngine);
sut.sendMessage(client, template);
verify(mailServer).send("some@email.com", msgContent);
Creation of a test spy using the mock() method.
The mailServer test spy is injected into SUT, so it can be used. Execution of the SUT’s sendMessage() method.
Verification of what happened during the execution of the SUT’s sendMessage() method. Has the SUT really invoked the send() method of mailServer with given parameters? Once again the code which does the verification is really easy to read: "verify that the send() method of mailServer was invoked with given email and message content".
In the case of our example we can use the test spy to actually verify the actions of the SUT. This is where real testing takes place: we check whether the SUT is behaving as we expect it to.
5.2.5. Mock
I feel I should say at least something about mocks, even though we do not really need them. Let me repeat that in functional terms, there is little difference between a mock and a test spy. What a test spy can do, a mock can also do (and vice versa). The difference lies in the syntax and in the flow of code within your test methods. The main purpose of the mock and the test spy are the same: to verify that some communication between objects has taken place: i.e. that some methods have been called. I have decided to devote Appendix C, Test Spy vs. Mock to a detailed discussion of the differences between test spies and mocks. But this is not something you need to know about. If you have grasped the idea of test spies, you can write perfect tests without knowing about mocks.
Do not worry that we haven’t really covered mocks! You can still put in your CV that you know how to mock classes. This is because mocking is about verifying the collaboration between the SUT and DOCs, and you are perfectly capable of doing this.
As regards our example, we could use a mock to cover exactly the same area that we decided to use a test spy for: to verify the expected behaviour of the SUT.
5.3. Putting it All Together
Once again, we go back to the code presented on Listing 5.12. In the previous sections we have been discussing the role of each test double – dummy, stub, test spy and mock – in testing this code. Now it is time to show them working together. But before the code is shown, a few words of warning.
It is very good that we are able to test such code using unit tests. It is really great, that we know how to isolate the SUT from the environment, how to control its direct and indirect inputs and outputs. It is
76
Chapter 5. Mocks, Stubs, Test Spies
perfect, that we have learned the difference between stubs, test spies, dummies and mocks. We will – well, you will – make use of this knowledge many, many times, and it will make you a better developer - I am quite sure of this. However, the decision about what should be tested on which level (with which type of test) is not an easy one. In fact, it requires one thing: experience. And the problem is that this can only be gained through blood, sweat and tears.
If I were to test the example shown in Listing 5.12, I would opt for a mixture of unit and integration tests. I would certainly use unit tests - in a manner that will be shown in a minute - to check for all the strange things that can happen, and which are hard to trigger when using real components. So, for example, I would make clientDAO return all kinds of unexpected result - e.g. throw an exception of the NoSuchUserInDatabase kind, and the like. Unit tests in conjunction with test doubles are just perfect for this kind of verification.
In parallel, I would use integration tests to see that my code really results in e-mails being sent. This means that I would:
•prepare an e-mail template and implement the TemplateEngine class, so that it really could then prepare a nice e-mail message,
•implement the MailServer class, so the e-mails really would be sent.
And only then, thanks to having written a few unit and integration tests, would I be able to sleep peacefully in my bed, resting assured that everything is fine with my code.
Having said that, let us now turn to a good example of a unit test, which is shown below. This will demonstrate our ability to write unit tests for such code. It proves that we know how to use the test doubles. But let us bear in mind that this is only a single test, chosen from many other tests - unit, integration and end-to-end - which would have to be written to fully cover the functionality considered here.
Listing 5.16. MessengerTest
public class MessengerTest {
private static final String CLIENT_EMAIL = "some@email.com"; 
private static final String MSG_CONTENT = "Dear John! You are fired.";
@Test
public void shouldSendEmail() {
Template template = mock(Template.class);
Client client = mock(Client.class);
MailServer mailServer = mock(MailServer.class);
TemplateEngine templateEngine = mock(TemplateEngine.class);
Messenger sut = new Messenger(mailServer, templateEngine);
when(client.getEmail()).thenReturn(CLIENT_EMAIL); 
when(templateEngine.prepareMessage(template, client))
.thenReturn(MSG_CONTENT);
sut.sendMessage(client, template);
verify(mailServer).send(CLIENT_EMAIL, MSG_CONTENT);
}
}
Some static value to be used within the test code.
77