How to use can_define_class_in_open_reading_private_module method of org.mockito.moduletest.ModuleHandlingTest class

The argThat return type is not being inferred for some reason. Try explicitly casting as shown below:

 Mockito.verify(foo).bar((Map<String, String>) argThat(Matchers.hasEntry("paramName", "paramValue")));

The testHasEntryCast() can be fixed as shown below. Notice that cast (Map<String, ?>) is to argThat return type:

@Test
public void testHasEntryCast() {
    Service mockService = mock(Service.class);
    Foo foo = new Foo(mockService);

    foo.bar();

    verify(mockService).activate((Map<String, ?>)  argThat(hasEntry("paramName", "paramValue")));
}

Since the method getApplicationContext is inside the class that you're extending it becomes somewhat problematic. There are a couple of problems to consider:

• You really can't mock a class that is under test, which is one of the many drawbacks with object inheritance (i.e. subclassing).
• The other problem is that ApplicationContext is a singleton, which makes it all more evil to test since you can't easily mock out a global state that is programmed to be irreplaceable.

What you can do in this situation is to prefer object composition over inheritance. So in order to make your Activity testable you need to split up the logic a little. Lets say that your Activity is called MyActivity. It needs to be composed of a logic component (or class), lets name it MyActivityLogic. Here is a simple class-diagram figure:

To solve the singleton problem, we let the logic be "injected" with an application context, so it can be tested with a mock. We then only need to test that the MyActivity object has put the correct application context into MyActivityLogic. How we basically solve both problems is through another layer of abstraction (paraphrased from Butler Lampson). The new layer we add in this case is the activity logic moved outside of the activity object.

For the sake of your example the classes need to look sort-of like this:

public final class MyActivityLogic {

    private MyApp mMyApp;

    public MyActivityLogic(MyApp pMyApp) {
        mMyApp = pMyApp;
    }

    public MyApp getMyApp() {
        return mMyApp;
    }

    public void onClick(View pView) {
        getMyApp().setNewState();
    }
}

public final class MyActivity extends Activity {

    // The activity logic is in mLogic
    private final MyActivityLogic mLogic;

    // Logic is created in constructor
    public MyActivity() {
        super(); 
        mLogic = new MyActivityLogic(
            (MyApp) getApplicationContext());
    }

    // Getter, you could make a setter as well, but I leave
    // that as an exercise for you
    public MyActivityLogic getMyActivityLogic() {
        return mLogic;
    }

    // The method to be tested
    public void onClick(View pView) {
        mLogic.onClick(pView);
    }

    // Surely you have other code here...

}

It should all look something like this:

To test MyActivityLogic you will only need a simple jUnit TestCase instead of the ActivityUnitTestCase (since it isn't an Activity), and you can mock your application context using your mocking framework of choice (since handrolling your own mocks is a bit of a drag). Example uses Mockito:

MyActivityLogic mLogic; // The CUT, Component Under Test
MyApplication mMyApplication; // Will be mocked

protected void setUp() {
    // Create the mock using mockito.
      mMyApplication = mock(MyApplication.class);
    // "Inject" the mock into the CUT
      mLogic = new MyActivityLogic(mMyApplication);
}

public void testOnClickShouldSetNewStateOnAppContext() {
    // Test composed of the three A's        
    // ARRANGE: Most stuff is already done in setUp

    // ACT: Do the test by calling the logic
    mLogic.onClick(null);

    // ASSERT: Make sure the application.setNewState is called
    verify(mMyApplication).setNewState();
}

To test the MyActivity you use ActivityUnitTestCase as usual, we only need to make sure that it creates a MyActivityLogic with the correct ApplicationContext. Sketchy test code example that does all this:

// ARRANGE:
MyActivity vMyActivity = getActivity();
MyApp expectedAppContext = vMyActivity.getApplicationContext();

// ACT: 
// No need to "act" much since MyActivityLogic object is created in the 
// constructor of the activity
MyActivityLogic vLogic = vMyActivity.getMyActivityLogic();

// ASSERT: Make sure the same ApplicationContext singleton is inside
// the MyActivityLogic object
MyApp actualAppContext = vLogic.getMyApp();
assertSame(expectedAppContext, actualAppContext);

Hope it all makes sense to you and helps you out.

Cache.put is final, so you need to use PowerMock if you want to mock it.

Your test would look like this:

@RunWith(PowerMockRunner.class)
@PrepareForTest(Cache.class)
public class EhCacheBaseTest {
    private static final String CACHE_NAME = "testCache";
    private CacheManager cacheManager;
    private Cache cache;
    private EhCacheBase<String, Object> ehCacheBase;

    @Before
    public void init() {
        // You can statically import mock method, but left it this way 
        // for clarity
        cacheManager = PowerMockito.mock(CacheManager.class);
        cache = PowerMockito.mock(Cache.class);
        ehCacheBase = new EhCacheBase<String, Object>(CACHE_NAME);
        EhCacheBase.setCacheManager(cacheManager);
    }

    @Test
    public void shouldRetrieveCacheAndPutOneValueInIt() {
        //given
        Object o = new Object();
        when(cacheManager.getCache(CACHE_NAME)).thenReturn(cache);

        //when
        ehCacheBase.cache("KEY", o);

        //then
        verify(cacheManager, times(1)).getCache(CACHE_NAME);
        verify(cache, times(1)).put(any(Element.class));
    }
}

One way could be to avoid being too restrictive on your arguments in order to provide all the expected results with only one thenReturn call.

For example let's say that I want to mock this method:

public String foo(String firstArgument, Object obj) {
    return "Something";
}

You could then mock it by providing as many results as you want like below:

// Mock the call of foo of any String to provide 3 results
when(mock.foo(anyString(), anyObject())).thenReturn("val1", "val2", "val3");

Calls to foo with any parameters will provide respectively "val1", "val2", then any subsequent calls will provide "val3".

In case you do care about passed values but don't want to depend on call sequence you can use thenAnswer to provide an answer that matches with the second argument like you currently do but with 3 different thenReturn. Assuming that you have overridden the method equals(Object o).

when(mock.foo(anyString(), anyObject())).thenAnswer(
    invocation -> {
        Object argument = invocation.getArguments()[1];
        if (argument.equals(new ARequest(1, "A"))) {
            return new AResponse(1, "passed");
        } else if (argument.equals(new ARequest(2, "2A"))) {
            return new AResponse(2, "passed");
        } else if (argument.equals(new BRequest(1, "B"))) {
            return new BResponse(112, "passed");
        }
        throw new InvalidUseOfMatchersException(
            String.format("Argument %s does not match", argument)
        );
    }
);

Or simply, using the methods anyString and eq as argument marchers. Assuming that you have overridden the method equals(Object o).

when(service.foo(anyString(), eq(new ARequest(1, "A"))))
    .thenReturn(new AResponse(1, "passed"));
when(service.foo(anyString(), eq(new ARequest(2, "2A"))))
    .thenReturn(new AResponse(2, "passed"));
when(service.foo(anyString(), eq(new BRequest(1, "B"))))
    .thenReturn(new BResponse(112, "passed"));

You need to inject mock inside the class you're testing. At the moment you're interacting with the real object, not with the mock one. You can fix the code in a following way:

void testAbc(){
     myClass.myObj = myInteface;
     myClass.abc();
     verify(myInterface).myMethodToBeVerified(new String("a"), new String("b"));
}

although it would be a wiser choice to extract all initialization code into @Before

@Before
void setUp(){
     myClass = new myClass();
     myClass.myObj = myInteface;
}

@Test
void testAbc(){
     myClass.abc();
     verify(myInterface).myMethodToBeVerified(new String("a"), new String("b"));
}

I would stub that Provider and make it return the prototypeMock every time using the @Before method invoked before each of the tests:

@Mock
private javax.inject.Provider<MyPrototype> prototypeFactoryStub;

@Mock 
MyPrototype prototypeMock;

@InjectMocks 
MySingleton sut;

@Before
public void init(){
   MockitoAnnotations.initMocks(this); // optional

   when(prototypeFactoryStub.get()).thenReturn(prototypeMock);
}

@Test
public void testPrototype() {
    sut.doStuff();
    verify(prototypeMock, times(1)).invoke();
}

I have written an article on Mockito Stubbing if you need a further read.

I think

Mockito.reset(wareHouseSpy)

would do it.

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).

By default, Maven assumes you wrote your code using JDK 1.5 and that you want to compile to that same target. You will need to add the maven-compiler-plugin to your build plugins, in order to tell it to use 1.8.

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.3</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
            </configuration>
        </plugin>
    </plugins>
</build>

Check out the plugin's docs for more info: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html