How to use getMock method of org.mockito.internal.listeners.VerificationStartedNotifier class

A good technique for getting rid of static calls on 3rd party API is hiding the static call behind an interface.

Let's say you make this interface :

interface IPDOFacade {

    IPDO getContextPDO();
}

and have a default implementation that simply calls the static method on the 3rd party API :

class IPDOFacadeImpl implements IPDOFacade {

    @Override
    public IPDO getContextPDO() {
        return Util.getContextPDO();
    }
}

Then it is simply a matter of injecting a dependency on the interface into MyClass and using the interface, rather than the 3rd party API directly :

public class MyClass {

    private final IPDOFacade ipdoFacade;

    public MyClass(IPDOFacade ipdoFacade) {
        this.ipdoFacade = ipdoFacade;
    }

    private IPDO getIPDO() {
        return ipdoFacade.getContextPDO();
    }

    public String handleIn(Object input) throws Throwable
    {
        String result = "";
        IPDO pdo = getIPDO();

        someImportantBusinessLogic(pdo);

        return result;
    }
    
    ...

}

In your unit test, you can then easily mock your own interface, stub it any way you like and inject it into the unit under test.

This

• avoids the need to make private methods package private.
• makes your tests more readable by avoiding partial mocking.
• applies inversion of control.
• decouples your application from a specific 3rd party library.

@Mock creates a mock. @InjectMocks creates an instance of the class and injects the mocks that are created with the @Mock (or @Spy) annotations into this instance.

Note you must use @RunWith(MockitoJUnitRunner.class) or Mockito.initMocks(this) to initialize these mocks and inject them (JUnit 4).

With JUnit 5, you must use @ExtendWith(MockitoExtension.class).

@RunWith(MockitoJUnitRunner.class) // JUnit 4
// @ExtendWith(MockitoExtension.class) for JUnit 5
public class SomeManagerTest {

    @InjectMocks
    private SomeManager someManager;

    @Mock
    private SomeDependency someDependency; // this will be injected into someManager
 
     // tests...

}

If the contract of class A includes the fact that it calls method B of an object of type C, then you should test this by making a mock of type C, and verifying that method B has been called.

This implies that the contract of class A has sufficient detail that it talks about type C (which might be an interface or a class). So yes, we're talking about a level of specification that goes beyond just "system requirements", and goes some way to describing implementation.

This is normal for unit tests. When you are unit testing, you want to ensure that each unit is doing the "right thing", and that will usually include its interactions with other units. "Units" here might mean classes, or larger subsets of your application.

Update:

I feel that this doesn't apply just to verification, but to stubbing as well. As soon as you stub a method of a collaborator class, your unit test has become, in some sense, dependent on implementation. It's kind of in the nature of unit tests to be so. Since Mockito is as much about stubbing as it is about verification, the fact that you're using Mockito at all implies that you're going to run across this kind of dependency.

In my experience, if I change the implementation of a class, I often have to change the implementation of its unit tests to match. Typically, though, I won't have to change the inventory of what unit tests there are for the class; unless of course, the reason for the change was the existence of a condition that I failed to test earlier.

So this is what unit tests are about. A test that doesn't suffer from this kind of dependency on the way collaborator classes are used is really a sub-system test or an integration test. Of course, these are frequently written with JUnit too, and frequently involve the use of mocking. In my opinion, "JUnit" is a terrible name, for a product that lets us produce all different types of test.

I've run into a problem like this before, with Mockito. I'm not sure why it happens yet. You can cast the expect(..) argument to the non-generic Class type, ala

expect((Class) mockBeanFactory.getType(CLASS_NAME)).andReturn(SOME_CLASS);

Then you'll just have a warning, which you can suppress if you want. Not a very elegant solution; I'm going to spend a few more minutes looking at it.

Use statement like this before mocked object compareTo() method calling:

when(mockedObject.compareTo(any(Sortable.class))).thenCallRealMethod();

There is no public API in Mockito for mock injection. Plus as this annotation is mostly driven on the way things are laid out in a test, it is fairly related to the initialization phase of the test.

Though it might change at some point in the future.

However Mockito annotated fields can be initialized either by the MockitoJUnitRunner or by MockitoAnnotations.initMocks(). They both create mock instances and perform injection.

Also I see in your code that you are using @Autowired - hence spring stuff, probably configured via XML. @InjectMocks wasn't really developed to work with other dependency injection frameworks, as the development was driven by unit test use cases, not integration tests.

You might want to take a look at springockito, which is another project that tries to ease Mockito mock creation in Spring.

Hope that helps

If you can't change the code, you can use Powermock along with junit and Mockito to mock the construction of new objects.

@Test
public void testDoWork() throws Exception{

    MyTest mytest = new MyTest();

    OtherObj obj = new OtherObj();
    obj.test="mocked Test"; //here you can add any other needed values to obj

    PowerMockito.whenNew(OtherObj.class).withNoArguments().thenReturn(obj);

    String result = mytest.doWork();
    Assert.assertTrue(result.equalsIgnoreCase("mocked Test"));
}

I wouldn't use exceptions to test that, but verifications. And another problem is that you can't use when() with methods returning void.

Here's how I would do it:

FizzConfigurator fixture = Mockito.spy(new FizzConfigurator());
doNothing().when(fixture).doWidget(Mockito.anyString(), Mockito.<Config>any()));
fixture.doBuzz("some string");
Mockito.verify(fixture).doWidget("some string", Config.SOMETIMES);

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.