How to use undesiredInteraction method of org.mockitousage.verification.BasicVerificationInOrderTest class

if you do a employee = new Employee(param1, param2); you may as well skip @InjectMocks.

It is supposed to do the following:

@InjectMocks
ClassUnderTest cut;

@Mock
Dependency1 dep1;
@Mock
Dependency2 dep2;

@Before
public void setup() {
  initMocks(this);
}

omitting @InjectMocks the same behaviour can be achieved with the following code:

ClassUnderTest cut;

@Mock
Dependency1 dep1;
@Mock
Dependency2 dep2;

@Before
public void setup() {
  initMocks(this);
  cut = new ClassUnderTest(dep1, dep2);
}

In your specific case, you should mock param1 and param2. Never call the constructor manually when using @InjectMocks.

This question is ancient, but Mockito v2.1.0+ now has a built-in feature for this.

verify(mock, description("This will print on failure")).someMethod("some arg");

More examples included from @Lambart's comment below:

verify(mock, times(10).description("This will print if the method isn't called 10 times")).someMethod("some arg");
verify(mock, never().description("This will print if someMethod is ever called")).someMethod("some arg");
verify(mock, atLeastOnce().description("This will print if someMethod is never called with any argument")).someMethod(anyString());

TL;DR; Unfortunately, there is no built-in solution yet (at time of writting, 2022), hence you are free to use and/or implement whatever fits your situation.

Example

An alternative is to use the CountDownLatch class.

public class DatabaseTest {

    /**
     * Data limit
     */
    private static final int DATA_LIMIT = 5;

    /**
     * Countdown latch
     */
    private CountDownLatch lock = new CountDownLatch(1);

    /**
     * Received data
     */
    private List<Data> receiveddata;

    @Test
    public void testDataRetrieval() throws Exception {
        Database db = new MockDatabaseImpl();
        db.getData(DATA_LIMIT, new DataCallback() {
            @Override
            public void onSuccess(List<Data> data) {
                receiveddata = data;
                lock.countDown();
            }
        });

        lock.await(2000, TimeUnit.MILLISECONDS);

        assertNotNull(receiveddata);
        assertEquals(DATA_LIMIT, receiveddata.size());
    }
}

NOTE you can't just used syncronized with a regular object as a lock, as fast callbacks can release the lock before the lock's wait method is called. See this blog post by Joe Walnes.

EDIT Removed syncronized blocks around CountDownLatch thanks to comments from @jtahlborn and @Ring

No, there is no reliable, supported way to do this. You assign a method reference to an instance of a functional interface, but that instance is cooked up by LambdaMetaFactory, and there is no way to drill into it to find the method you originally bound to.

Lambdas and method references in Java work quite differently than delegates in C#. For some interesting background, read up on invokedynamic.

Other answers and comments here show that it may currently be possible to retrieve the bound method with some additional work, but make sure you understand the caveats.

You are reusing your context, in order to have tests independent from one another you probably need to refresh your context after each test to reset everything.

I will suppose you are using Junit 4.5+. It would be similar with other test frameworks.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"mycontext.xml"})
@DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD)
public class MyTestClass {
...
    // my tests    
...
}

You can put the @DirtiesContext at the method level if the methods that need "fixing" are few, but if you are using Spring your best option is to do it after every test.

Anyway, I don't think you should be using mocks/spies in integration tests:

• In unit tests, use mocks (if you want) and inject manually. Here you want to verify the behaviour of your tested bean as a unit, so you isolate it from the rest by using mocks. This also has the advantage that JUnit isolates your tests by using a different instance of the test class for each test, so unless you use static or other test-unfriendly practices everything will just work.

• In integration tests, use real beans and let Spring inject. Here the goal is to verify that beans interact well with one another / with the environment (database, network, ...) You do not want to isolate beans here, so you should not use mocks.

See Spring documentation about testing for more detailed explanations.

To verify the number of times it was invoked, use verify(spiedObject, times(x)).doSomething().

You should NOT be verifying the value returned from the spied object. It is not the object under test so why verify what it returns. Instead verify the behavior of the object under test in response to the value returned from the spy.

Also, if you don't KNOW what value will be returned by the spied object it would be better to use a mock instead of a spy.

For @Async semantics to be adhered, some active @Configuration class will have the @EnableAsync annotation, e.g.

@Configuration
@EnableAsync
@EnableScheduling
public class AsyncConfiguration implements AsyncConfigurer {

  //

}

To resolve my issue, I introduced a new Spring profile non-async.

If the non-async profile is not active, the AsyncConfiguration is used:

@Configuration
@EnableAsync
@EnableScheduling
@Profile("!non-async")
public class AsyncConfiguration implements AsyncConfigurer {

  // this configuration will be active as long as profile "non-async" is not (!) active

}

If the non-async profile is active, the NonAsyncConfiguration is used:

@Configuration
// notice the missing @EnableAsync annotation
@EnableScheduling
@Profile("non-async")
public class NonAsyncConfiguration {

  // this configuration will be active as long as profile "non-async" is active

}

Now in the problematic JUnit test class, I explicitly activate the "non-async" profile in order to mutually exclude the async behavior:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = Application.class)
@WebAppConfiguration
@IntegrationTest
@Transactional
@ActiveProfiles(profiles = "non-async")
public class SomeServiceIntTest {

    @Inject
    private SomeService someService;

        @Test
        public void testAsyncMethod() {

            Foo testData = prepareTestData();

            someService.asyncMethod(testData);

            verifyResults();
        }

        // verifyResult() with assertions, etc.
}

I had the same error but for me it was caused by the fact that I had ommited the ID as URL parameter. I ommited it because the ID was present in the JSON body.

When I changed .../restaurant to ...restaurant/1, the error went away.

Test without CDI

A simple solution is to combine CDI with Constructor Injection, and forget about Guice for the test:

public class MyCommand {
    private final MyService service;

    @Inject
    public MyCommand(MyService service) {
        this.service = service;
    }

    public boolean executeSomething() {
        return service.doSomething() > 0;
    }
}

@RunWith(MockitoJUnitRunner.class)
public class MyCommandTest {
    @Mock
    MyServiceImpl serviceMock;
    private MyCommand command;

    @Before public void beforeEach() {
        MockitoAnnotations.initMocks(this);
        when(serviceMock.doSomething()).thenReturn(-1); // <- Error here

        // inject without Guice
        command = new MyCommand(serviceMock);
    }
}

Test with Mockito doing CDI

Else, if you do not like Constructor Injection, the test code should look like this:

@RunWith(MockitoJUnitRunner.class)
public class MyCommandTest {
    @Mock
    MyServiceImpl serviceMock;
    @InjectMocks 
    private MyCommand command;

    private AutoCloseable mockHandler;

    @Before
    public void beforeEach() {
        // initialize members annotated with @Mock and @InjectMocks
        mockHandler = MockitoAnnotations.openMocks(this);

        when(serviceMock.doSomething()).thenReturn(-1); // <- Error here
    }

    @After
    public void afterEach() throws Exception {
        mockHandler.close();
    }
}