How to use reportOr method of org.mockito.internal.progress.ArgumentMatcherStorageImpl class

You can just write

verify(service).perform((Collection<String>) Matchers.argThat(contains("a", "b")));

From the compiler's point of view, this is casting an Iterable<String> to a Collection<String> which is fine, because the latter is a subtype of the former. At run time, argThat will return null, so that can be passed to perform without a ClassCastException. The important point about it is that the matcher gets onto Mockito's internal structure of arguments for verification, which is what argThat does.

You should also mock the next() method to have it return true the first time it's called, as mockito will return false by default.

Mockito.when(resultSetMock.next()).thenReturn(true).thenReturn(false);

It's counting your setup as invocations since deeps stubs is not supported in the verification API, and complains on the second call which is:

when(mockSandBox.getSand().doB()).thenReturn(1);

I would skip using RETURNS_DEEP_STUBS and just use another mock:

...
@Mock
SandBox mockSandBox;

@Mock
Sand sand;

@Test
public void should(){
    when(mockSandBox.getSand()).thenReturn(sand);
    when(sand.doA()).thenReturn(1);
    when(sand.doB()).thenReturn(1);
    when(sand.doC()).thenReturn(1);
...

It is possible for third-party plugins to register custom MockMaker implementations that create classes differently to the default behavior via Mockito's SPI. As a part of the specified behavior, since Mockito 2.0, a MockMaker can decide if a class is mockable, such as final classes in the case of PowerMock. In order to integrate such a custom behavior, PowerMock registers a custom MockMaker that is then used by Mockito.

In Mockito 2.0, the API for a custom MockMaker had to be extended but PowerMock does not yet adapt the API extensions. Therefore, this new method is not yet implemented by the PowerMock MockMaker what results in an AbstractMethodError.

I've never used Mockito, but want to learn, so here goes. If someone less clueless than me answers, try their answer first!

Mockito.when(reader.document(anyInt())).thenAnswer(new Answer() {
 public Object answer(InvocationOnMock invocation) {
     Object[] args = invocation.getArguments();
     Object mock = invocation.getMock();
     return document(fakeIndex((int)(Integer)args[0]));
     }
 });

If this is really a maven project and you are using matching m2e-version 1.9, it should automatically configure the "Contains test sources."-setting and the related settings correctly.

You may have to update the project classpath by right-clicking on the project and Choosing "Maven" > "Update Project"

Mockito doesn't generate any byte code at compile time and hence is not affected by the used compiler. Same holds true for dexmaker. (they don't have any hooks into Gradle during build)

So you can simply continue to use Mockito, even with Jack compiler. Note that I have a test project which confirms this.

like this,

MyClass c = new MyClass(); 
someClassICanMock  m = mock(someClassICanMock.class);
doNothing().when(m).doSomething();
MyClass s = spy(c);
s.methodToTest();
verify(s , times(1)).methodFromSameClassIWantToVerify();

@RunWith(MockitoJUnitRunner.class)

With this declaration you are suppose to write a unit test. Unit tests are exercising a single class mocking all dependencies. Typically you will inject mocked dependencies declared like this in your test case:

@Mock
private YourDependency yourDependencyMock;

@RunWith(SpringJUnit4ClassRunner.class)

Spring runner is meant for integration test (component test?) In this type of tests you are exercising a whole bunch of classes, in other words you are testing a single class with real dependencies (testing a controller with real services, DAOs, in-memory database, etc.)

You should probably have both categories in your application. Althought it is advices to have more unit tests and only few smoke integration tests, but I often found myself more confident writing almost only integration tests.

As for your second question, you should have:

• unit tests for each class (controller, services, DAOs) separately with mocked all other classes

• integration tests for a whole single CRUD operation. For instance creating a user that exercises controller, service, DAO and in-memory database.