使用 Mockito.when() 模拟和验证 vs mockito.verify

Question

Imagine you have method someMethod , how would you go by to test it?

Mockito.when(someClass.someMethod(someParam)).thenReturn(someValue);
var bar = foo() // SUT: ends upp calling someMethod somewhere in the stack
assertThat(bar).isEqualTo(someValue);

vs

Mockito.when(someClass.someMethod(someParam)).thenReturn(someValue);
var bar = foo() // SUT: ends upp calling someMethod somewhere in the stack
verify(someClass, times(1)).someMethod(someParam)
assertThat(bar).isEqualTo(someValue);

It is true that the Mockito.when is "kind of" verifying that someClass.someMethod is being called with the correct arguments. Personally I like the idea of having clear assertions/verifications so that the tests can serve as a form of documentation. I don't like giving my mocks double-responsibilities, I want to keep my mocks just simply as "mocks". So back to my question.

What is the preferred way, using Mockito.when combined with Mockito.verify or only Mockito.when ?

Answer 1

When defines the behaviour of the Mock - declaratively defining the way the mock will respond when methods are invoked with different parameters. Verify is used to check whether the Mock has been interacted with in various ways.

Here are some URLS to the official Mockito documentation, which I hope will help.

• Stubbing - with when
• Argument matchers
• Verification in order
• Making sure interaction(s) never happened on mock

It's probably worth performing a search for some other examples.

Answer 2

I think this question has been answered in https://stackoverflow.com/a/35301264/473064 .

The summary is:

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.

One point that I would add is that sometimes if we want to do a verifyZeroInterations to ensure that no unexpected calls occurred, we would have to first exhaust the known calls by verify ing them.

What I usually do is to perform the simplest verify(mock, times(n)).someMethod(anyClass()) as generally as possible without repeating the more specific argument matching that I have already specified in the stubbing, which reduces the duplication as much as possible.

Example:

when(someObject.someMethod(eq("abc"))).thenReturn(someValue);
when(someObject.someMethod(eq("def"))).thenReturn(otherValue);
when(someObject.someMethod(endsWith("suffix"))).thenReturn(anotherValue);

var bar = foo();

assertEquals(expectedBar, bar);

verify(someObject, times(3)).someMethod(anyString());
verifyZeroInteractions(someObject);

Regarding your concern in the comment:

The problem I see is, if a new developer reads the test, they won't know the subbed method is part of the verification process.

The stubbed method is not part of the verification process. It's part of the test case setup, ie, the Given step.

I think your example might be a little bit misleading. The final output from foo() is usually a transformation of the response from someMethod , ie, someValue in the example. So if the stubbed method is not called and returned with the correct value, the test would have failed anyway. The said developer would then have to look at the mocking and understand how the test case works.

In the updated example below, there is no need to verify that someMethod is called because if it didn't get called, the assertion would fail.

Mockito.when(someClass.someMethod(someParam)).thenReturn(someValue);
var bar = foo() // SUT: ends upp calling someMethod somewhere in the stack
var expectedValue = // a value depending on `someValue`
assertThat(bar).isEqualTo(expectedValue);