How to use toInvocationMatcher method of org.mockito.internal.invocation.InvocationBuilder class

import org.springframework.test.util.ReflectionTestUtils;

@RunWith(MockitoJUnitRunner.class)
public CustomServiceTest{

@InjectMocks
private CustomServiceImpl customService;

@Mock
private DataService dataService;

@Before
public void setup() {
    ReflectionTestUtils.setField(customService, "url", "http://someurl");
}    
...
}

As mentioned on the mockito github:

It looks like this has to do with calling when the second time. I couldn't find what was going on, but the second when doesn't attempt to add the mock logic, it just calls the method. Replacing with doReturn().when() works.

    doReturn(expected1).when(overloadedMethods).getString(any());
    doReturn(expected2).when(overloadedMethods).getString(any(), any());

https://github.com/mockito/mockito/issues/1496#issuecomment-423310950 DavidTanner

This stub is wrong :

doNothing().when(mockObject.methodToStub(captor.capture())); // wrong

methodToStub(...) must be outside the when if using this API style (it should only contain the mock) :

doNothing().when(mockObject).methodToStub(captor.capture()); // correct

Tho remarks however :

1. doNothing is the default for void methods for a mock.
2. You can use the BDDMockito aliases that enables your code to be real à la Behavior Driven Development

Your test doesn't test any of your code. It tests that Mockito works fine.

When I introduce the concept of mocking, I take this example: suppose you build a detonator, and want to test it. You could of course use the detonator with a real bomb, and see if the whole block explodes when you use the detonator. But that isn't very practical. BTW, maybe you don't even have a bomb at your disposal. Maybe your colleague is still building it.

So you use a mock bomb. Note the important point: to test the detonator, you use a mock bomb. Not a mock detonator. What is mocked is the dependency of the class under test. Not the class under test itself.

What is a mock bomb? It's just a fake bomb that doesn't do anything. All it does is allowing to verify if has been asked to explode or not. So your code to test the detonator would be like this:

// create a mock bomb:
Bomb mockBomb = mock(Bomb.class);
// create a real detonator, but tie it to the mock bomb:
Detonator detonator = new Detonator(mockBomb);

// test the detonator. Since it's tied to a mock bomb, the block
// won't explode
detonator.pressTheRedButton();

// check it the mock bomb has been asked to explode, as it should 
// if the detonator works correctly
verify(mockBomb).explode();

Now if the test passes, you know that all the internal circuitry that is used in pressTheRedButton() works fine and eventually tells the bomb to explode. So you know that, when used with a real bomb, the real bomb will be asked to explode as well when pressing the red button.

Now let's come back to the real world: you want to test a service, and this service uses a DAO that needs a database, populated with data, to run fine. To test your service, you can simply mock the DAO, and verify it works fine. The mock DAO can also be used as a stub, i.e. an object that returns what you tell it to return in the test, instead of actually querying the database. That's what you're doing in the code in your question: you're telling the mock MyClass instance that, when add() is called with 2 and 2 as arguments, it should return 4.

This makes the test easier to setup, faster to run, and independant from the actual code of the DAO, which is not what you want to test in the unit test of the service.

As a temporary workaround, you can do the following:

trait MockitoHelper extends MockitoSugar {
  def doReturn(toBeReturned: Any): Stubber = {
    Mockito.doReturn(toBeReturned, Nil: _*)
  }
}

Then have your test mixin this MockitoHelper.

I just had this error and worked through the solution. My pom.xml file had the following dependency:

<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-mockito-release-full</artifactId>
  <version>1.5</version>
  <classifier>full</classifier>
  <scope>test</scope>
</dependency>

The problem comes from the fact my code uses JUnit and the above dependency has an external dependency on TestNG. This was stopping my test from running. Why I don't know - you would have though a test framework would have been tested a little bit better!!!

Anyway the solution was to break down the 'full' dependencies to just those required:

<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-api-mockito</artifactId>
  <version>1.5</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-core</artifactId>
  <version>1.5</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-module-junit4</artifactId>
  <version>1.5</version>
  <scope>test</scope>
</dependency>

That solved it. BTW I used mvn dependency:tree to understand the associated dependencies.

When you want to use the @Mock annotation you should use the MockitoJUnitRunner

@RunWith(MockitoJUnitRunner.class)
public class MockitoTest {

    @Mock
    private IRoutingObjHttpClient routingClientMock;

    @Test
    public void testSendRoutingRequest() throws Exception {
        // ...
    }

}

See also this tutorial.

First of all the reason for mocking MyHandler methods can be the following: we already test anotherMethod() and it has complex logic, so why do we need to test it again (like a part of someMethod()) if we can just verify that it's calling?
We can do it through:

@RunWith(MockitoJUnitRunner.class)
class MyHandlerTest {

  @Spy  
  @InjectMocks  
  private MyHandler myHandler;  

  @Mock  
  private MyDependency myDependency;  

  @Test  
  public void testSomeMethod() {  
    doReturn(1).when(myHandler).anotherMethod();  
    assertEquals(myHandler.someMethod() == 1);  
    verify(myHandler, times(1)).anotherMethod();  
  }  
}  

Note: in case of 'spying' object we need to use doReturn instead of thenReturn(little explanation is here)

The response by david-wallace explains why you run into an OOM: a mock object is remembering details of every invocation.

But an equally important question is: now what to do about it? In addition to what David already suggested, the latest Mockito versions 1.10.19 as well as upcoming 2.0.x now support so-called stubOnly mocks (see javadoc):

stubOnly: A stub-only mock does not record method invocations, thus saving memory but disallowing verification of invocations.

Scala usage example:

import org.mockito.Mockito
val list = Mockito.mock(classOf[Foo], Mockito.withSettings().stubOnly())

// The syntax is a bit more concise when using ScalaTest's MockitoSugar
val foo = mock[Foo](Mockito.withSettings().stubOnly())

Java usage example (untested):

import org.mockito.Mockito;
Foo mock = Mockito.mock(Foo.class, Mockito.withSettings().stubOnly());