Complex Stubbing with Mockito for Java

2013-02-01 6:33

Mocks are used to “fake” the behavior of objects to the extent required by tests. Most of the time, they can be pretty simple: when calling a method with given set of (constant) argument, then return some predefined value. Mocking frameworks actually strive to translate the previous sentence directly into code, which can be seen in Java’s Mockito library:

@Mock private SomeBuilder someBuilder;
@Mock private SomeObject someObject;
private void mockSomeBuilder() {
when(someBuilder.setFoo(anyString())).thenReturn(someBuilder);
when(someBuilder.setBar(anyInt())).thenReturn(someBuilder);
when(someBuilder.build()).thenReturn(someObject);
}

What is evident here is that this mock doesn’t maintain any state. As a result, all stubbed method are completely independent and referentially transparent: they always return the same value for the same set of arguments. In reality, that property is even stronger because they are simply constant.

Simple mocks like those work for a good number of cases. Some may even argue that it’s the only way to mock properly, because anything more complicated is a sign of code smell. We can counter that by saying that some complexity is often unavoidable, and it’s up to developers to decide whether they want to put it test or tested code.

And thus more complex stubbing may be needed if, for some case, you prefer the former approach. When that happens, it’s good to know how to fabricate a bit more sophisticated behavior. In Mockito, it’s very possible to achieve almost arbitrary complexity by capturing arguments of stubbed calls and routing them to callbacks. This is done with the help of ArgumentCaptor class and the Answer interface, respectively.
When combined, they can result in pretty clever mocks, as illustrated with this example of some imaginary API for SMTP (e-mail sending protocol):

@Mock private SmtpConnection smtpConnection;
private void mockSmtpConnection() {
final ArgumentCaptor<String> recipient = ArgumentCaptor.forClass(String.class);
final ArgumentCaptor<String> subject = ArgumentCaptor.forClass(String.class);
final ArgumentCaptor<String> body = ArgumentCaptor.forClass(String.class);
when(smtpConnection.setRecipient(recipient.capture()))
.thenReturn(smtpConnection);
when(smtpConnection.setSubject(subject.capture()))
.thenReturn(smtpConnection);
when(smtpConnection.setMessage(body.capture()))
.thenReturn(smtpConnection);
when(smtpConnection.getOutgoingClientData())
.thenAnswer(new Answer<String> {
@Override
public String answer(InvocationOnMock call) {
return recipient.getValue() + "\0"
+ subject.getValue() + "\0"
+ body.getValue();
}
});
}

Note that it doesn’t implement the real SMTP. That, presumably, would mimic the SmtpConnection class exactly, which of course is not the point of mocking at all.
The point is to provide sufficiently complete behavior so that code under test can proceed, reaching all the execution paths we want to exercise. In this case, something can call getOutgoingClientData and rely on certain string being present in the output.

Let’s just hope that this “something” actually has some good reasons to expect that…

Be Sociable, Share!

Tags: Java, Mockito, mocks, testing, unit tests
Author: Xion, posted under Computer Science & IT »

« License It, Please

Now That’s What I Call a History Lesson »

Adding comments is disabled.

Comments are disabled.