How to use shouldCreateRunnerInstance method of org.mockito.internal.runners.util.TestMethodsFinderTest class

While a partial mock isn't a bad idea, you might find your code easier to follow if you use an ArgumentCaptor instead to get the values after the fact. It's a special argument matcher that keeps track of the value it matches.

// initialized with MockitoAnnotations.initMocks();
@Captor ArgumentCaptor<Integer> offsetCaptor;
@Captor ArgumentCaptor<float[]> floatsCaptor;
@Mock Bar bar;

@Test
public void valuesShouldBeCloseEnough() {
  Sut sut = new Sut(bar);
  sut.doSomething();
  verify(bar).setFoo(offsetCaptor.capture(), floatsCaptor.capture());

  // check values with assertValuesAreCloseEnough, declared elsewhere
  assertValuesAreCloseEnough(offsetCaptor.getValue(), floatsCaptor.getValue());
}

You can use a mock object to verify that you have called it in the way expected. In Mockito, mocked objects are automatically stubs, and verification occurs explicitly.

From Mockito's "Why do we need another mocking framework?":

 Separation of stubbing and verification. Should let me code in line with intuition: 
 stub before execution, selectively verify interactions afterwards. I don’t 
 want any verification-related code before execution.

You can stub the behavior of calls before they're called. For example (from the Mockito home page):

 when( mockedList.get(0)).thenReturn( "first" );

You can verify interactions with mocked objects after they're called. For example:

 verify( mockedList ).add("one");

when(
  fooDao.getBar(
    any(Bazoo.class)
  )
).thenReturn(myFoo);

or (to avoid nulls):

when(
  fooDao.getBar(
    (Bazoo)notNull()
  )
).thenReturn(myFoo);

Don't forget to import matchers (many others are available):

For Mockito 2.1.0 and newer:

import static org.mockito.ArgumentMatchers.*;

For older versions:

import static org.mockito.Matchers.*;

It's a defect in Mockito with loading plugins when context class loader is different from which is used to load PowerMock and Mockito.

It could be fixed in Mockito 2, but as it mentioned in comments

Not sure we have the build infrastructure to backport the fix on 1.x

For Mockito 1, fix cannot be delivered, so I fixed in in PowerMock and fix will be include in next PowerMock release (PowerMock 1.6.5).

Alright, once I realised that the class was being proxied due to the @Transactional annotation, the solution to the problem became clearer. What I needed to do was unwrap the proxy, and set the mocked object directly on that:

So in my AbstractIntegrationTest:

/**
 * Checks if the given object is a proxy, and unwraps it if it is.
 *
 * @param bean The object to check
 * @return The unwrapped object that was proxied, else the object
 * @throws Exception
 */
public final Object unwrapProxy(Object bean) throws Exception {
    if (AopUtils.isAopProxy(bean) && bean instanceof Advised) {
        Advised advised = (Advised) bean;
        bean = advised.getTargetSource().getTarget();
    }
    return bean;
}

Then in my @Before:

@Mock
private ProcessHelper processHelper;

@Before
public void setUp() throws Exception {
    MockitoAnnotations.initMocks(this);

    IXMLBatchProcessor iXMLBatchProcessor = (IXMLBatchProcessor) unwrapProxy(xmlProcessor);
    ReflectionTestUtils.setField(iXMLBatchProcessor , "processHelper", processHelper);
}

This left all the @Autowired classes intact, while injecting the correct mocked object.

It looks like Gradle is not doing it's job. Manually adding the jars may fixed the problem. How to Download and Install jar go here .

and for download mockito use this link

https://mvnrepository.com/artifact/org.mockito/mockito-core/1.10.19

UPDATE

There are newer java7 versions that fix this issue. As is written in reply to Powermock / Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7 #525

upgrading from java 7u71 to 7u75 fixed the problem

Rootcause

Upon investigation I heard cries for help from all over the internet from all tools and languages that built upon JDK.

Turns out the cause is new java bytecode standard that gets checked by new verifier. But unfortunately javassist sometimes is asked by powermock to produce changes into bytecode that are no longer accepted by this new shiny veryfier.

Workaround (for those who cannot go with newer java)

As a workaround in JRebel blog they suggested using -noverify flag upon starting JVM However i found from Java 7 Bytecode Verifier: Huge backward step for the JVM blog post alternative workaround that works on java7: -XX:-UseSplitVerifier

As my tests run in some unaccessible server and are executed as part of maven build, i needed to find a way to pass that argument along with my project files. First workable solution i discovered is to add this parameter to configurtaion of surefire plugin in pom.xml as follows:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.10</version>
            <configuration>
                <argLine>-XX:-UseSplitVerifier</argLine>
            </configuration>
        </plugin>
        <plugin>
    </plugins>
</build>

I suppose that on java8 one could use similar method to call tests with -noverify key, but haven't had the chance to confirm that.

Other related resources to keep eye on

Powermock / Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7. Powermock / Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7 #525

You haven't mocked the behavior of getId in externalDependencyObject therefore it is returning null and giving you the NPE when toString() is called on that null.

You need a when(externalDependencyObject.getId()).then...

I got this to work by doing this in the test:

CompletableFuture<Long> future = new CompletableFuture<>();
future.completeExceptionally(new Exception("HTTP call failed!"));

Mockito.when(mockClient.getSize())
        .thenReturn(future);

Not sure if this is the best way though.