How to use no_stubbing_arg_mismatch_when_no_mismatch_on_fail method of org.mockitousage.junitrule.StubbingWarningsJUnitRuleTest class

It is because of Java/Mockito compatibility. For example, if you are using Java 11 with Mockito 2.17.0, it will throw the same error (Upgrading to Mockito 2.22.0 or later will solve it). Aside from digging into their release artifact on Github, I am yet to see a comprehensive document that spells out the compatibility matrix. Here is a helpful compatibility Matrix (based on quick test)

• Mockito * - 2.17.0 => Java 8

(footnote: * - dont know how far back)

• Mockito 2.18.0 - 3.2.4 => Java 11

Finally I got some times to investigate and I made it. Here is my solution.

@RunWith(PowerMockRunner.class)
@PowerMockRunnerDelegate(VertxUnitRunner.class)
@PrepareForTest({ MongoClient.class })
public class PersistenceTest {

private MongoClient mongo;
private Vertx vertx;

@Before
public void initSingleTest(TestContext ctx) throws Exception {
  vertx = Vertx.vertx();
  mongo = Mockito.mock(MongoClient.class);
  PowerMockito.mockStatic(MongoClient.class);
  PowerMockito.when(MongoClient.createShared(Mockito.any(), Mockito.any())).thenReturn(mongo);
  vertx.deployVerticle(Persistence.class, new DeploymentOptions(), ctx.asyncAssertSuccess());
}

@SuppressWarnings("unchecked")
@Test
public void loadSomeDocs(TestContext ctx) {
  Doc expected = new Doc();
  expected.setName("report");
  expected.setPreview("loremipsum");
  Message<JsonObject> msg = Mockito.mock(Message.class);
  Mockito.when(msg.body()).thenReturn(JsonObject.mapFrom(expected));
  JsonObject result = new JsonObject().put("name", "report").put("preview", "loremipsum");
  AsyncResult<JsonObject> asyncResult = Mockito.mock(AsyncResult.class);
  Mockito.when(asyncResult.succeeded()).thenReturn(true);
  Mockito.when(asyncResult.result()).thenReturn(result);
  Mockito.doAnswer(new Answer<AsyncResult<JsonObject>>() {
    @Override
    public AsyncResult<JsonObject> answer(InvocationOnMock arg0) throws Throwable {
    ((Handler<AsyncResult<JsonObject>>) arg0.getArgument(3)).handle(asyncResult);
    return null;
    }
  }).when(mongo).findOne(Mockito.any(), Mockito.any(), Mockito.any(), Mockito.any());
  Async async = ctx.async();
  vertx.eventBus().send("persistence", new JsonObject(), msgh -> {
    if (msgh.failed()) {
    System.out.println(msgh.cause().getMessage());
    }
    ctx.assertTrue(msgh.succeeded());
    ctx.assertEquals(expected, Json.decodeValue(msgh.result().body().toString(), Doc.class));
    async.complete();
  });
  async.await();
  }
}

Use Powemockito to mock the MongoClient.createShared static method, so you'll have your mock when verticle starts. Mocking async handler is a bit of code to write. As you can see mocking start at Message<JsonObject> msg = Mockito.mock(Message.class); and ends at Mockito.doAnswer(new Answer.... In the Answer's method pick the handler param and force it to handle your async result then you're done.

I think you do need to cast it, but it shouldn't be too bad:

Foo<Bar> mockFoo = (Foo<Bar>) mock(Foo.class);
when(mockFoo.getValue()).thenReturn(new Bar());

Fail the test if an exception is caught.

@Test
public void testGetBalanceForPerson() {

   // creating mock person
   Person person1 = mock(Person.class);
   when(person1.getId()).thenReturn("mockedId");

   // calling method under test
   try {
      myClass.getBalanceForPerson(person1);
   } catch(Exception e) {
      fail("Should not have thrown any exception");
   }
}

You could solve this by two ways.

Using Mock:

Page<TaskEntity> tasks = Mockito.mock(Page.class);
Mockito.when(this.taskRepository.findAll(org.mockito.Matchers.isA(Pageable.class))).thenReturn(tasks);

Or, Using class instantiation:

List<TaskEntity> tasks = new ArrayList<>();
Page<TaskEntity> pagedTasks = new PageImpl(tasks);
Mockito.when(this.taskRepository.findAll(pagedTasks)).thenReturn(pagedTasks);

If you are able to set a fixed number of calls to expect, it can be done with an ArgumentCaptor:

import static org.hamcrest.CoreMatchers.hasItem;

@Captor ArgumentCaptor<String> arg;

@Before
public void setUp() throws Exception {
    // init the @Captor
    initMocks(this);
}

@Test
public void testWithTimeoutCallOrderDoesntMatter() throws Exception {
    // there must be exactly 99 calls
    verify(myMock, timeout(5000).times(99)).myMethod(arg.capture());
    assertThat(arg.getAllValues(), hasItem("expectedArg"));
}

Another way is to specify all the expected values to verify, but those need to be provided in the exact order that they are invoked. The difference to the above solution is that this doesn't fail even if the mock is additionally called with some non-verified arguments. In other words, no need to know the number of total invocations. Code example:

@Test
public void testWithTimeoutFollowingCallsDoNotMatter() throws Exception {
    // the order until expected arg is specific
    verify(callback, timeout(5000)).call("firstExpectedArg");
    verify(callback, timeout(5000)).call("expectedArg");
    // no need to tell more, if additional calls come after the expected arg
    // verify(callback, timeout(5000)).call("randomArg");
}

You can use PowerMockito

See the example:

Second second = Mockito.mock(Second.class);
whenNew(Second.class).withNoArguments().thenReturn(second);

But re-factoring is better decision.

Spring's MockHttpServletRequest and MockHttpServletResponse are useful for that purpose. E.g.

    MockHttpServletRequest request = new MockHttpServletRequest();
    MockHttpServletResponse response = new MockHttpServletResponse();
    request.addHeader(HttpHeaders.HOST, "myhost.com");
    request.setLocalPort(PORT_VALID); // e.g. 8081
    request.setRemoteAddr(REQUEST_IP); // e.g. 127.0.0.1

then I can call myclass.method(request, response, ...) and check whether some attribute has been correctly set into the request, e.g.

    MyBean attr = (MyBean) request.getAttribute(ATTRIBUTE_NAME));
    // do my Assert.* stuff with 'attr'

MockHttpServletRequest and MockHttpServletResponse work fine where mock(HttpServletRequest.class) fails, for instance where you need to get back the real content of a request attribute which has been previously set within your business logic.

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 before verify() gets executed). If your code doesn't care what get(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. 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…

Recent versions of Mockito (released since this Q&A was posted) have added some additional features that allow or default to stricter mocking styles. Despite this, the prevailing expectation is to avoid brittleness by only verifying what you can't confirm through assertions or successful test completion.

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.