How to use VerificationWrapperInOrderWrapper method of org.mockito.internal.verification.DummyVerificationMode class

Since java 8, the compiler type inference have been greatly improved.

Now you could remove the class parameter from the matcher without any compilation warning:

when(implClassMock.executeTask(any())).thenReturn(null);

Note: i have the same compiler failure but only with eclipse. A bug may be ?

As per the documentation (Mockito 1 and Mockito 2), you have to use argThat(matcher), a Mockito matcher which allows you to use your custom argument matchers:

 //stubbing
 when(mock.giveMe(argThat(new MyHamcrestMatcher())));

 //verification
 verify(mock).giveMe(argThat(new MyHamcrestMatcher()));

You did not say if you're using Mockito 1 or 2, but the idea is similar, it's just the static import that is different:

• 1: import static org.mockito.Matchers.argThat; (or for simplicity org.mockito.Mockito which extends Matchers)
• 2: import static org.mockito.hamcrest.MockitoHamcrest.argThat;

Bonus hint, for readability you can replace times(0) with never(), so in your case it would be:

verify(customPublisher, never()).publish(argThat(isFailureResult()), anyObject());

PropertyDescriptor#getPropertyType() returns an object of Class<?>, where the ? means "this is a type, but I don't know what it is". Let's call this type "X". So when(mockDescriptor.getPropertyType()) creates an OngoingStubbing<Class<X>>, whose method thenReturn(Class<X>) can only accept objects of Class<X>. But the compiler doesn't know what type this "X" is, so it will complain about you passing in a Class of any type. I think this is the same reason the compiler complains about calling add(...) on a Collection<?>.

When you explicitly specify Class<?> for the type on the when method, you're not saying that mockDescriptor.getPropertyType() returns a Class<?>, you're saying that when returns an OngoingStubbing<Class<?>>. Then, the compiler checks to make sure whatever you're passing into when is of a type that matches Class<?>; since getPropertyType() returns the "Class<X>" I mentioned earlier, it of course matches the Class<?> you specified.

So basically

// the inferred type is Class<"some type">
Mockito.when(mockDescriptor.getPropertyType())

// the specified type is Class<"any type">
Mockito.<Class<?>>when(mockDescriptor.getPropertyType())

In my IDE, the error message for your original code is

The method thenReturn(Class<capture#1-of ?>) in the type OngoingStubbing<Class<capture#1-of ?>> is not applicable for the arguments (Class<String>)

That capture#1-of ? is the "X" I described above.

I would recommend approach #1, but would use Spring for dependency injection rather than instantiating DAOs directly.

This way, for unit testing the client code, you can substitue mock DAOs, and verify that the correct DAOs are invoked with the appropriate arguments. (Mockito is useful here.)

If you use static methods, then unit testing is much more difficult, since static methods cannot be overridden.

You can create a file as part of the test, no need to mock it out.

JUnit does have a nice functionality for creating files used for testing and automatically cleaning them up using the TemporaryFolder rule.

public class MyTestClass {

    @Rule
    public TemporaryFolder folder = new TemporaryFolder();

    @Test
    public void myTest() {
        // this folder gets cleaned up automatically by JUnit
        File file = folder.newFile("someTestFile.txt");

        // populate the file
        // run your test
    }
}

Try Cntrl + Shift + T on your eclipse screen. Check what are your results. Ideally eclipse should resolve this class only from one dependency. If you are getting multiple results, you may need to add exclusion on certain dependencies.

Also check if you are able to execute your test cases from command prompt. If you are able to do it, then it's not a maven problem. But if something is failing here, check your dependencies.

I was able to completely answer my own question.

In this example an address with the Locality of Louisville is generated while the other fields look like "address.getStreet1();".

private Address createAddress(){
    Address address = mock(Address.class, new StringAnswer() );

    when(address.getLocality()).thenReturn("Louisville");

    ISOCountry isoCountry = mock(ISOCountry.class);
    when(isoCountry.getIsocode()).thenReturn("US");
    when(address.getCountry()).thenReturn(isoCountry);

    return address;
}

private class StringAnswer implements Answer<Object> {
    @Override
    public Object answer(InvocationOnMock invocation) throws Throwable {
           if( invocation.getMethod().getReturnType().equals(String.class)){
               return invocation.toString();
           }
           else{
               return Mockito.RETURNS_DEFAULTS.answer(invocation);
           }
       }
}

I've finally been able to solve my problem. The key to the answer is the line

java.lang.IllegalStateException: Could not self-attach to current VM using external process

For Java 9 and more, one must add -Djdk.attach.allowAttachSelf=true as VM argument to avoid this exception. When I did, unit tests ran perfectly.

Here are the links where I've found this :

https://github.com/raphw/byte-buddy/issues/612

https://github.com/mockk/mockk/issues/254

Of course, I could write something like don't use singleton, they are evil, use Guice/Spring/whatever but first, this wouldn't answer your question and second, you sometimes have to deal with singleton, when using legacy code for example.

So, let's not discuss the good or bad about singleton (there is another question for this) but let's see how to handle them during testing. First, let's look at a common implementation of the singleton:

public class Singleton {
    private Singleton() { }

    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }

    public String getFoo() {
        return "bar";
    }
}

There are two testing problems here:

1. The constructor is private so we can't extend it (and we can't control the creation of instances in tests but, well, that's the point of singletons).

2. The getInstance is static so it's hard to inject a fake instead of the singleton object in the code using the singleton.

For mocking frameworks based on inheritance and polymorphism, both points are obviously big issues. If you have the control of the code, one option is to make your singleton "more testable" by adding a setter allowing to tweak the internal field as described in Learn to Stop Worrying and Love the Singleton (you don't even need a mocking framework in that case). If you don't, modern mocking frameworks based on interception and AOP concepts allow to overcome the previously mentioned problems.

For example, Mocking Static Method Calls shows how to mock a Singleton using JMockit Expectations.

Another option would be to use PowerMock, an extension to Mockito or JMock which allows to mock stuff normally not mock-able like static, final, private or constructor methods. Also you can access the internals of a class.