How to use triggerStubbing method of org.mockitousage.debugging.VerificationListenerCallBackTest class

I had a test dependency on a third-party jar which used powermock. In order to resolve this error, I had to add:

@PowerMockIgnore("jdk.internal.reflect.*")

To the class that is tested with powermock

You can write your custom matcher that will pass this condition.

 class NotNullObjects extends ArgumentMatcher<Review> {
     public boolean matches(Object object) {
         return object!=null;
     }
 }

Then usage

when(reviewBuilder.saveReviewModel(argThat(new NotNullObjects()))).thenReturn(2L);

My one advice is to think of some interface that you can expect there as na input of your method.

The first issue is that you have to use spyTemp object to expect something from Mockito. Here it is not the same as test. spyTemp is wrapped by the Mockito object temp.

Another issue is that you stub only methodB(), but you are trying to run methodA(). Yes in your implementation of methodA() you call methodB(), but you call this.methodB(), not spyTemp.methodB(). Here you have to understand that mocking would work only when you call it on the instance of temp. It's wrapped by a Mockito proxy which catches your call, and if you have overriden some method, it will call your new implementation instead of the original one. But since the original method is called, inside it you know nothing about Mockito proxy. So your "overriden" method would be called only when you run spyTemp.methodB()

This should work:

Mockito.doReturn(true).when(spyTemp).methodB(Mockito.any()); 
boolean status = spyTemp.methodA("XYZ");

Do not mock the client stub, or any other final class/method. The gRPC team may go out of their way to break your usage of such mocks, as they are extremely brittle and can produce "impossible" results.

Mock the service, not the client stub. When combined with the in-process transport it produces fast, reliable tests. This is the same approach as demonstrated in the grpc-java hello world example.

@Rule
public final GrpcCleanupRule grpcCleanup = new GrpcCleanupRule();

@Test
public void test() {
    // This can be a mock, but is easier here as a fake implementation
    BlahServiceImplBase serviceImpl = new BlahServiceImplBase() {
        @Override public void blah(Request req, StreamObserver<Response> resp) {
            resp.onError(new StatusRuntimeException(Status.UNAVAILABLE));
        }
    };
    // Note that the channel and server can be created in any order
    grpcCleanup.register(InProcessServerBuilder.forName("mytest")
        .directExecutor().addService(serviceImpl).build().start());
    ManagedChannel chan = grpcCleanup.register(
        InProcessChannelBuilder.forName("mytest").directExecutor().build();
    BlahServiceBlockingStub blahServiceBlockingStub
        = BlahServiceGrpc.newBlockingStub();

    blahServiceBlockingStub.blah(null);
}

When doing multiple tests, you can hoist the server, channel, and stub creation into fields or @Before, out of the individual tests. When doing that it can be convenient to use MutableHandlerRegistry as a fallbackHandlerRegistry() on the server. That allows you to register services after the server is started. See the route guide example for a fuller example of that approach.

Some of the other answers offer alternatives to doing exactly what I want here, but this is doable by Spying the Consumer class itself and having the spy call the method you really want to execute. A helper method for wrapping the lambda to create the spy helps here:

/** Get a spied version of the given Consumer. */
private Consumer<Item> itemHandlerSpy(Consumer<Item> itemHandler) {
  // Create a spy of the Consumer functional interface itself.
  @SuppressWarnings("unchecked")
  Consumer<Item> spy = (Consumer<Item>) Mockito.spy(Consumer.class);
  // Tell the spy to run the given consumer when the Consumer is given something to consume. 
  Mockito.doAnswer(it -> {
    // Get the first (and only) argument passed to the Consumer.
    Item item = (Item) it.getArguments()[0];
    // Pass it to the real consumer so it gets processed.
    itemHandler.accept(item);
    return null;
  }).when(spy).accept(Mockito.any(Item.class));
  return spy;
}

And then the test method becomes very straightforward:

Consumer<Item> itemHandler = itemHandlerSpy(Item::foo);
instance.conditionalRun(itemHandler);
// This verifies conditionalRun called the Consumer exactly once.
Mockito.verify(itemHandler).accept(Mockito.any(Item.class));

This should work

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.verify;

verify(bar).DoStuff(any(Foo[].class));

Refering to this tutorial on Mockito, you can see that Mockito do call the original method.

There is only one caveat to this syntax. The real rule.createFileTemplate() method will be called once. This can have a lot of side effects and might even fail throwing an exception (very often a NPE). To solve this, you can (should?) use this alternative Mockito syntax:

doReturn(mockFileTemplate).when(rule).createFileTemplate();

In order to avoid this you should use the other syntax of Mockito doReturn().when()

doThrow(new Exception("Testing")).when(spy).methodB();

Hope this help.

EDIT :

Please notice that the structure is a little bit different than the when().thenReturn().

doThrow(new Exception("Testing"))
    .when(spy)
    .methodB();

you can set the value using reflection. It doesn't need any change in production code.

ReflectionTestUtils.setField(YourClass.class, "fieldName", fieldValue);

From an identical issue that I just ran into, I suspect that sample is a mock, and you stubbed sample.getId() elsewhere? That caused this problem in my case, anyhow.

For some reason, Mockito gets upset if one of the arguments you pass to the stub used with doThrow in this way is the result of a method you also mocked. Perhaps it's a re-entrancy check of sorts to avoid infinite loops, I don't know.

Regardless, try replacing sample.getId() with a constant value and that should solve the issue. You could consider using a constant declared in your test for both the mock and any further uses of it. You could then also check that sample.getId() was used by the method you're testing by adding another call to verify.