I often see the same methods being verified as the methods being mocked in Mockito
(example below). Is there any added benefit to call Mockito.verify()
in these cases?
//mock method
FooService fs = mock(FooService.class);
when(fs.getFoo()).thenReturn("foo");
//method under test
fs.doSomething();
//verify method
verify(fs).getFoo();
The method should fail if fs.getFoo()
is not called. So why call verify
? I see the benefit if you need to use ArgumentCaptor
in the verify to assert the parameters; besides the ArgumentCaptor case, is it just unnecessary?
We can mock runInGround(String location) method inside the PersonTest class as shown below. Instead of using mock(class) here we need to use Mockito. spy() to mock the same class we are testing. Then we can mock the method we want as follows.
Internally Mockito uses Point class's equals() method to compare object that has been passed to the method as an argument with object configured as expected in verify() method. If equals() is not overridden then java. lang.
Mockito verify() method can be used to test number of method invocations too. We can test exact number of times, at least once, at least, at most number of invocation times for a mocked method. We can use verifyNoMoreInteractions() after all the verify() method calls to make sure everything is verified.
The Mockito documentation repeatedly says it is often redundant. This appears verbatim both in verify(T)
's Javadoc as multiple single-line comments in the code block in Mockito's main class Javadoc section 2:
Although it is possible to verify a stubbed invocation, usually it's just redundant. If your code cares what
get(0)
returns, then something else breaks (often even beforeverify()
gets executed). If your code doesn't care whatget(0)
returns, then it should not be stubbed. Not convinced? See here.
Note that the originally linked article, "Asking and Telling", was written by Mockito originator Szczepan Faber and can be considered an authoritative document in Mockito's design. (As of 2022, the site is down and the link is removed from documentation; I've linked to the Archive.org mirror for consistency.) To excerpt from that post:
Do I really have to repeat the same expression? After all, stubbed interactions are verified implicitly. The execution flow of my own code does it completely for free. Aaron Jensen also noticed that:
If you’re verifying you don’t need to stub unless of course that method returns something that is critical to the flow of your test (or code), in which case you don’t really need to verify, because the flow would have verified.
Just to recap: there is no repeated code.
But what if an interesting interaction shares the characteristic of both asking and telling? Do I have to repeat interactions in stub() and verify()? Will I end up with duplicated code? Not really. In practice: If I stub then it is verified for free, so I don’t verify. If I verify then I don’t care about the return value, so I don’t stub. Either way, I don’t repeat myself. In theory though, I can imagine a rare case where I do verify a stubbed interaction, for example to make sure the stubbed interaction happened exactly n times. But this is a different aspect of behavior and apparently an interesting one. Therefore I want to be explicit and I am perfectly happy to sacrifice one extra line of code…
Overall, Mockito's design is to allow tests to be as flexible as possible, coding not to the implementation but instead to the spec of the method you're testing. Though you'll occasionally see a method call as part of a function's spec ("Submits an RPC to the server" or "Calls the passed LoginCallback immediately"), it's much more likely that you'll want to validate the postconditions that you can infer from the stubs: Checking that getFoo
was called isn't really a part of the spec as long as you stubbed getFoo
to return "foo" and the data store contains a single object with its corresponding property set to "foo".
In short, it is considered good Mockito style to explicitly verify only the interactions that can't be implied from well-crafted stubs and postcondition assertions. They may be good calls for otherwise-unmeasurable side effects—logging code, thread executors, ArgumentCaptors, multiple method calls, callback functions—but generally should not be applied to stubbed interactions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With