How to use PluginFileReader class of org.mockito.internal.configuration.plugins package

Iterator mockIterator = mock(Iterator.class);
doCallRealMethod().when(fruits).forEach(any(Consumer.class));
when(fruits.iterator()).thenReturn(mockIterator);
when(mockIterator.hasNext()).thenReturn(true, false);
when(mockIterator.next()).thenReturn(mockObject);

I would do this in one of the following ways:

1. Inject the key.
2. Stub the method call and set the key there.

Method 1 When I say inject the key I actually mean inject a KeyFactory. This means you can control the result within your test. For example:

KeyHolder newCode = injectedKeyFactory.getKeyHolder();
try {
    namedParameterJdbcTemplate.update(sql, paramMap, newCode);
} catch (DuplicateKeyException e) {
    logger.error("Duplicate Key");
}
data.setId(newCode.getKey().intValue());

Then in the test:

KeyHolder newCode = mock(KeyHolder.class);
Mockito.when(namedParameterJdbcTemplate.update(Mockito.anyString(), Mockito.any(MapSqlParameterSource.class), newCode)).thenReturn(1);
Mockito.when(newCode.getKey()).thenReturn(__preferredId__);

The key factory is a simple one which just returns a new GeneratedKeyHolder. It gets injected at construction time, so this method does assume you're using DI.

Method 2

Mockito.when(namedParameterJdbcTemplate.update(Mockito.anyString(), Mockito.any(MapSqlParameterSource.class), Mockito.any(GeneratedKeyHolder.class))).thenAnswer(new Answer() {
    Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        Map<String, Object> keyMap = new HashMap<String, Object>();
        keyMap.put("", __preferredId__);
        ((GeneratedKeyHolder)args[2]).getKeyList().add(keyMap);
    }
}).andReturn(1);

I've not really used Mockito, so sorry if the code's not quite right. :)

OK. So, the contract of the method is the following: Parse the input string as JSON, and send back BAD_REQUEST if it's invalid. If it's valid, create an entity in the datastore with various properties (you know them), and send back OK.

And you need to verify that this contract is fulfilled by the method.

Where does Mockito help here? Well, if you test this method without Mockito, you need a real DataStoreService, and you need to verify that the entity has been created correctly in this real DataStoreService. This is where your test is not a unit test anymore, and this is also where it's too complex to test, too long, and too hard to run because it needs a complex environment.

Mockito can help by mocking the dependency on the DataStoreService: you can create a mock of DataStoreService, and verify that this mock is indeed called with the appropriate entity argument when you call your initialize() method in your test.

To do that, you need to be able to inject the DataStoreService into your object under test. It can be as easy as refactoring your object in the following way:

public class MyRestService {
    private DataStoreService dataStoreService;

    // constructor used on the server
    public MyRestService() {
        this.dataStoreService = DatastoreServiceFactory.getDatastoreService();
    }

    // constructor used by the unit tests
    public MyRestService(DataStoreService dataStoreService) {
        this.dataStoreService = dataStoreService;
    }

    public Response initialize(String DatabaseSchema) {
         ...
         // use this.dataStoreService instead of datastore
    }
}

And now in your test method, you can do:

@Test
public void testInitializeWithGoodInput() {
    DataStoreService mockDataStoreService = mock(DataStoreService.class);
    MyRestService service = new MyRestService(mockDataStoreService);
    String goodInput = "...";
    Response response = service.initialize(goodInput);
    assertEquals(Response.Status.OK, response.getStatus());

    ArgumentCaptor<Entity> argument = ArgumentCaptor.forClass(Entity.class);
    verify(mock).put(argument.capture());
    assertEquals("the correct kind", argument.getValue().getKind());
    // ... other assertions
}

Update (9/07/2015):

You can continue to work with 22.2.1 if you use the following excludes:

androidTestCompile ('com.android.support.test.espresso:espresso-core:2.2') {
    exclude group: 'com.android.support', module: 'support-annotations'
}
androidTestCompile ('com.android.support.test:runner:0.3') {
    exclude group: 'com.android.support', module: 'support-annotations'
}
androidTestCompile ('com.android.support.test:rules:0.3') {
    exclude group: 'com.android.support', module: 'support-annotations'
}

If you depend on espresso-contrib, you need the exclude as well.

Update (8/03/2015):

With support library 22.2.1, the dependencies are broken again; please don't upgrade to 22.2.1 until a new runner is released.

Update (6/04/2015):

With the latest release of runner 0.3 and rules 0.3, this answer is no longer needed. You can simply use

androidTestCompile 'com.android.support.test:runner:0.3'
androidTestCompile 'com.android.support.test:rules:0.3'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2'

with latest support libraries. (22.2.0 as of this writing)

Update (5/30/2015):

compile 'com.android.support:appcompat-v7:22.2.0'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2'
// com.android.support.test:testing-support-lib:0.1 // <-- causes issue

Update (4/24/2015):

The problem is that com.android.support:support-v4:22.1.1 is clashing with com.android.support.test:runner:0.2 (as that depends on com.android.support:support-v4:22.0.0).

com.android.support.test.espresso:espresso-core:2.1 has a dependency on com.android.support.test:runner:0.2, so it also causes the same error.

So, this combination will work:

compile 'com.android.support:support-v4:22.0.0'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.1'

...and so will this one (without 'com.android.support.test:runner:0.2'):

compile 'com.android.support:support-v4:22.1.0'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.0'

Original Answer:

Contrary to what the Espresso documentation says, you should remove this dependency:

androidTestCompile 'com.android.support.test:runner:0.2'

As it is the cause for library version conflict.

You should also update to Android gradle plugin 1.1.1, as that version will tell you the exact version conflict, which is useful in this case.

any() returns null. This choice was inevitable because the signature of any() is

public static <T> T any()

Since generic types are erased in Java, and since nothing is passed to the method that carries any type information (such as a Class<T>), null is the only reasonable return value.

This creates a problem if the method of the mock has an argument of primitive type because unboxing this null value throws a NullPointerException.

There are two possible solutions. You can either use the primitive versions (such as anyDouble()), or the version accepting a Class (e.g. any(Double.class)). In the latter case, since we are supplying type information to the method, it is possible to use this information to return a sensible non-null value (e.g. 0.0D in the case of double).

You can easily create your own HandlerMethod without mocking. There's a constructor that accepts an Object (the controller) and a Method (the controller method). The easiest way to get a Method is to simply call Class.getMethod(). What you want to do is just create a dummy controller class, and then use that class to get the method. For example

class TestController {
    @Custom
    public void testMethod() {}
}

Method method = TestController.class.getMethod("testMethod");
TestController controller = new TestController();
HandlerMethod handlerMethod = new HandlerMethod(controller, method);

Custom annotation = handlerMethod.getMethodAnnotation(Custom.class);

It's that easy. Below is a complete test.

public class HandlerInterceptorTest {

    @Target(ElementType.METHOD)
    @Retention(RetentionPolicy.RUNTIME)
    private @interface Custom {
    }

    private static class MyHandlerInterceptor implements HandlerInterceptor {

        @Override
        public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object handler) {
            if (handler instanceof HandlerMethod) {
                HandlerMethod handlerMethod = (HandlerMethod) handler;
                Custom annotation = handlerMethod.getMethodAnnotation(Custom.class);
                if (annotation != null) {
                    return true;
                }
            }
            return false;
        }
    }

    private static class TestController {
        @Custom
        public void testMethodWithAnnotation() {}

        public void testMethodWithoutAnnotation() {}
    }

    @Test
    public void testMethodWithAnnotation() throws Exception {
        Method method = TestController.class.getMethod("testMethodWithAnnotation");
        TestController controller = new TestController();
        HandlerMethod handlerMethod = new HandlerMethod(controller, method);

        MyHandlerInterceptor interceptor = new MyHandlerInterceptor();
        boolean result = interceptor.preHandle(null, null, handlerMethod);

        assertTrue(result);
    }

    @Test
    public void testMethodWithoutAnnotation() throws Exception {
        Method method = TestController.class.getMethod("testMethodWithoutAnnotation");
        TestController controller = new TestController();
        HandlerMethod handlerMethod = new HandlerMethod(controller, method);

        MyHandlerInterceptor interceptor = new MyHandlerInterceptor();
        boolean result = interceptor.preHandle(null, null, handlerMethod);

        assertFalse(result);
    }
}

On a first glance, the answer is simply: well, there are several mocking frameworks out there, and there are different ways to use them.

The first example tells JUnit to use the "unit test runner" that the Mockito mocking framework provides. The second example uses the unit test runner from the PowerMock framework.

In order for things to make sense, you would also have different import statements, as both frameworks have different implementations for the @Mock annotation for example.

( the main point of using these framework-specific test runners is that they take care of initializing all the fields with special framework-specific annotations ).

So: the difference here is simply that: the first example is written to use the Mockito framework, the second one uses PowerMock.

Now, which one of those to use?

Answer: Mockito.

Why? Somehow an ugly truth is: the PowerMock-one basically is a cry for help. It says "the class under test is badly designed, please fix it". Meaning: as a developer, you can write "easy to test" code, or "hard to test" code. Many people do the second: they write code that is hard to test. And then, PowerMock(ito) provides means to still test that code.

PowerMock(ito) gives you the ability to mock (thus control) calls to static methods, and to new(). To enable that, PowerMock(ito) manipulates the byte code of your code under test. That is perfectly fine for small code bases, but when you face millions of lines of production code, and thousands of unit tests, things are totally different.

I have seen many PowerMock tests fail for no apparent reason, to find out hours later ... that some "static" thing somewhere else was changed, and that somehow affect a different PowerMock static/new driven test case.

At some point, our team made a conscious decision: when you write new code, and you can only test that with PowerMock ... that isn't acceptable. Since then, we only created Mockito test cases, and not once since then we saw similar bizarre problems that bugged us with PowerMock.

The only acceptable reason to use PowerMock is when you want to test existing (maybe 3rd party) code that you do not want to modify. But of course, what is the point of testing such code? When you can't modify that code, why should tests fail all of a sudden?

An alternative approach would be to use the 'method to class' pattern.

1. Move the methods out of the customer class into another class/classes, say CustomerSomething eg/CustomerFinances (or whatever it's responsibility is).
2. Add a constructor to Customer.
3. Now you don't need to mock Customer, just the CustomerSomething class! You may not need to mock that either if it has no external dependencies.

Here's a good blog on the topic: https://simpleprogrammer.com/back-to-basics-mock-eliminating-patterns/

Technically speaking both "mocks" and "spies" are a special kind of "test doubles".

Mockito is unfortunately making the distinction weird.

A mock in mockito is a normal mock in other mocking frameworks (allows you to stub invocations; that is, return specific values out of method calls).

A spy in mockito is a partial mock in other mocking frameworks (part of the object will be mocked and part will use real method invocations).