How to use VerifiableInvocationsFinder method of org.mockito.internal.invocation.finder.VerifiableInvocationsFinder class

Your problem is the order of execution. The context is created containing your MockBean before you have a chance to set it up in your @Test. The solution is to provide a RestTemplateBuilder that's already fully setup when it's inserted into the context. You can do that like this.

Add the following to your @SpringBootTest annotation. Where TestApplication is your Spring Boot application class.

classes = {TestApplication.class, MyIT.ContextConfiguration.class},

Modify your class members thus, deleting your restTemplate and restTemplateBuilder.

@Autowired
private TestRestTemplate testRestTemplate;

Add a static inner class to your MyIT class:

@Configuration
static class ContextConfiguration {
  @Bean
  public RestTemplateBuilder restTemplateBuilder() {

    RestTemplateBuilder rtb = mock(RestTemplateBuilder.class);
    RestTemplate restTemplate = mock(RestTemplate.class);

    when(rtb.build()).thenReturn(restTemplate);
    return rtb;
  }
}

In your tests, modify the RestTemplate mock to do whatever you want:

@Test
public void someTest() {

  when(testRestTemplate.getRestTemplate().getForEntity(...
}

Since you are loading configuration class MyApplication.class datasource bean will be created, Try moving datasource in another bean which is not used in a test, make sure all classes loaded for tests are not dependant on datasource.
Or
In your tests create a config class marked with @TestConfiguration and include it in SpringBootTest(classes=TestConfig.class) mocking data source there like

@Bean
public DataSource dataSource() {
    return Mockito.mock(DataSource.class);
}

But this may fail since method call to this mocked datasouce for connection will return null, In that case, you'll have to create an in-memory datasource and then mock jdbcTemplate and rest of dependencies.

The following code templates will both create a logger and create the right imports, if needed.

SLF4J

${:import(org.slf4j.Logger,org.slf4j.LoggerFactory)}
private static final Logger LOG = LoggerFactory.getLogger(${enclosing_type}.class);

Log4J 2

${:import(org.apache.logging.log4j.LogManager,org.apache.logging.log4j.Logger)} 
private static final Logger LOG = LogManager.getLogger(${enclosing_type}.class); 

Log4J

${:import(org.apache.log4j.Logger)}
private static final Logger LOG = Logger.getLogger(${enclosing_type}.class);

Source.

JUL

${:import(java.util.logging.Logger)}
private static final Logger LOG = Logger.getLogger(${enclosing_type}.class.getName());

You need to use mockito-inline version 3.4.0 or higher and remove mockito-core from your dependencies (mockito-inline depends on mockito-core so it will be retrieved automatically).

That way, you will be using mockito static mocking correctly, but it wouldn't solve the exception that you posted.

To fix it, you need to remove all dependencies of powermock as it conflicts with mockito and causes this error

The used MockMaker PowerMockMaker does not support the creation of static mocks

It tested this with Mockito 1.9.5 and it works:

@Test
public void foo() {
    Runnable outer = Mockito.mock(Runnable.class, "outer");
    Runnable inner = Mockito.mock(Runnable.class, "inner");

    outer.run();
    inner.run();
    outer.run();

    InOrder order = Mockito.inOrder(outer, inner);
    order.verify(outer).run();
    order.verify(inner).run();
    order.verify(outer).run();
}

So if you aren't doing anything else wrong your code should work. What Mockito version are you using?

• any() checks absolutely nothing. Since Mockito 2.0, any(T.class) shares isA semantics to mean "any T" or properly "any instance of type T".

  This is a change compared to Mockito 1.x, where any(T.class) checked absolutely nothing but saved a cast prior to Java 8: "Any kind object, not necessary of the given class. The class argument is provided only to avoid casting."

• isA(T.class) checks that the argument instanceof T, implying it is non-null.

• same(obj) checks that the argument refers to the same instance as obj, such that arg == obj is true.

• eq(obj) checks that the argument equals obj according to its equals method. This is also the behavior if you pass in real values without using matchers.

  Note that unless equals is overridden, you'll see the default Object.equals implementation, which would have the same behavior as same(obj).

If you need more exact customization, you can use an adapter for your own predicate:

• For Mockito 1.x, use argThat with a custom Hamcrest Matcher<T> that selects exactly the objects you need.
• For Mockito 2.0 and beyond, use Matchers.argThat with a custom org.mockito.ArgumentMatcher<T>, or MockitoHamcrest.argThat with a custom Hamcrest Matcher<T>.

You may also use refEq, which uses reflection to confirm object equality; Hamcrest has a similar implementation with SamePropertyValuesAs for public bean-style properties. Note that on GitHub issue #1800 proposes deprecating and removing refEq, and as in that issue you might prefer eq to better give your classes better encapsulation over their sense of equality.

With mockito 2.x, JDK 8 default methods are supported.

With mockito 1.x it's not possible,

Old answer

Unfortunately it's not yet possible (mockito 1.10.19), from the README.md on the github'page

JDK8 status

Mockito should work fine with JDK8 if you stay away from default methods (aka defender methods). Lambda usage may work just as good for Answers. We're unsure about every JDK8 features at the moment, like serializing a mock that uses a lambda. Error report and pull request are welcome though (contributing guide).

EDIT 1: defender methods and default methods are different names for the same thing.

I hope for a mockmaker replacement that will handle java 8 opcodes properly for such cases as some opcodes have a different semantic in Java 8.

EDIT 2: Updated the mockito readme, and this quote accordingly

Not possible through mockito. From their wiki

Why Mockito doesn't mock private methods?

Firstly, we are not dogmatic about mocking private methods. We just don't care about private methods because from the standpoint of testing private methods don't exist. Here are a couple of reasons Mockito doesn't mock private methods:

It requires hacking of classloaders that is never bullet proof and it changes the api (you must use custom test runner, annotate the class, etc.).

It is very easy to work around - just change the visibility of method from private to package-protected (or protected).

It requires me to spend time implementing & maintaining it. And it does not make sense given point #2 and a fact that it is already implemented in different tool (powermock).

Finally... Mocking private methods is a hint that there is something wrong with OO understanding. In OO you want objects (or roles) to collaborate, not methods. Forget about pascal & procedural code. Think in objects.

This sounds very much like you have the wrong version of the servlet API in the class path.

Check when isAsyncStarted was added to the API and make sure the one you reference in your classpath is at least that version or higher.

In order to find the location where the 'wrong' class version is comming from you can use the

-verbose:class

Argument for java. It will list all the classes loaded and if I remember correctly whery they get loaded from. See http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html for details.