How to use shouldFindAllMatchingUnverifiedChunks method of org.mockito.internal.invocation.InvocationsFinderTest class

I'm not sure if your library is stored in a maven repository or not. I assume it is.

I know of two ways of importing a gradle project into IntelliJ. The first being the "Import Project..." wizard from IntelliJ which works nicely. But it does not import the javadoc jars if they exist. At least I never managed it.

The second method uses the idea plugin in gradle 2.1. The plugin generates the project for you. This way I got the javadoc inside. A fully working example for a build.gradle:

apply plugin: 'java'
apply plugin: 'idea'

sourceCompatibility = '1.7'
targetCompatibility = '1.7'

repositories {
    mavenCentral()
}

dependencies {
    compile group: 'org.apache.commons', name: 'commons-compress', version: '1.8.1'
    compile group: 'com.google.guava', name: 'guava', version: '18.0'

    testCompile group: 'junit', name: 'junit', version: '4.11'
    testCompile group: 'org.mockito', name: 'mockito-all', version: '1.8.5'
}

idea{
    project {
        languageLevel = '1.7'
    }
    module {
        downloadJavadoc = true // defaults to false
        downloadSources = true
    }
}

The you can call gradle cleanIdea idea which creates your project for IntelliJ.

If your library is not stored in a maven repository you can simply put up a nexus where you upload it. This would allow you to use the method described above.

JMockit can handle final and static. Just pay attention to how to set it up as it requires the -javaagent JVM parameter, or classpath tweaks, or extra annotations to be able to mock final and static stuffs.

Why it didn't work

You're mocking Result.iterator():

when(deviceDataResultMock.iterator()).thenReturn(resultIterator);

But you didn't mock Result.spliterator(), or at least I didn't see it, which is what's being called by Result.stream(), which is just Collection.stream():

default Stream<E> stream() {
    return StreamSupport.stream(spliterator(), false);
}

So, you'll have to mock the spliterator() method as well, and probably a few others, too! Alternatively, tell Mockito to call default methods:

Can you make mockito (1.10.17) work with default methods in interfaces?

A comment on mocking in general

I'm not convinced that mocking the jOOQ API is a very good idea. The jOOQ API is vast, and you'll likely forget to mock this or that method as this question here has aptly shown. With your current setup, you're planning on updating your mock every time you project a new column? E.g. you're doing this:

when(recordMock.get(DEVICEID.getName()).thenReturn(deviceId);

What if the column is renamed? Or another column is projected? You'll have to update this test. That feels like quite the chore, and it's very error prone.

While jOOQ itself has JDBC mocking capabilities, please consider the bold disclaimer on that manual page:

Disclaimer: The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is NOT RECOMMENDED to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database product instead for integration testing, rather than implementing your test database inside of a MockDataProvider

When working with databases, it's usually best to resort to running integration tests, see the following resources for some details:

• Integration testing with Jooq
• Using H2 as a Test Database Product with jOOQ
• How to Integration Test Stored Procedures with jOOQ
• Using Testcontainers to Generate jOOQ Code

Of course, you can write a few smoke tests to ensure jOOQ works correctly if you don't trust jOOQ (jOOQ being an external dependency). But the jOOQ unit and integration tests are vast, so in general, you should be able to trust core types like Result or Record to do the right thing for you. What you really want to test is your query correctness, and that, you can only integration test against an actual database instance.

Since Mockito 1.9.5+ and Java 8+

You can use a lambda expression, like:

when(myMock.myFunction(anyString())).thenAnswer(i -> i.getArguments()[0]);

Where i is an instance of InvocationOnMock.

For older versions

You can create an Answer in Mockito. Let's assume, we have an interface named MyInterface with a method myFunction.

public interface MyInterface {
    public String myFunction(String abc);
}

Here is the test method with a Mockito answer:

public void testMyFunction() throws Exception {
    MyInterface mock = mock(MyInterface.class);
    when(mock.myFunction(anyString())).thenAnswer(new Answer<String>() {
    @Override
    public String answer(InvocationOnMock invocation) throws Throwable {
        Object[] args = invocation.getArguments();
        return (String) args[0];
    }
    });

    assertEquals("someString",mock.myFunction("someString"));
    assertEquals("anotherString",mock.myFunction("anotherString"));
}

Mockito 1.8.1 introduced anyVararg() matcher:

when(a.b(anyInt(), anyInt(), Matchers.<String>anyVararg())).thenReturn(b);

Also see history for this: https://code.google.com/archive/p/mockito/issues/62

Edit new syntax after deprecation:

when(a.b(anyInt(), anyInt(), ArgumentMatchers.<String>any())).thenReturn(b);

Use when(spy.myMethod()).thenReturn(null). This will prevent the spy from invoking the wrapped instance. You have to tell Mockito what to return for a method that returns something. The default behavior for a mock is to return null. The default behavior for a spy is to call the wrapped object. When you stub a method in a spy it prevents the call to the wrapped object and executes the specified behavior.

Per documents of Spy, you could also do doReturn(null).when(spy).myMethod();

By annotating the BImpl field with @Mock, you're saying that the instance itself should be a mock. However, you're not telling Mockito what result the mock should give when invoked with arguments, so Mockito uses its default behaviour of returning null.

The fact that BImpl is a real class with real behaviour is irrelevant. The field does not contain an instance of that class; it contains an instance of a mock.

In your test method, before you call aImpl.doSomething(), tell mockito the behaviour you expect it to use:

when(bImpl.permuteString("test")).thenReturn("someOtherValue");

Well yes - the actual code of Foo doesn't matter, because you're mocking it... and Mockito doesn't know there's meant to be a relationship between setName and getName. It doesn't assume that it should store the argument to setName and return it when getName is called... it could do that, but it doesn't as far as I'm aware. The mock provided by Mockito just allows you to specify what happens when methods are called on it, and check what was called later on. Instead of calling setName, you could mock a call to getName() and specify what it should return...

... or you could just use Foo directly instead of mocking it. Don't think you have to mock everything in your tests. Just mock (or fake) things that are awkward when you're using the real class, e.g. because it uses the file system or network.

You can also use the non-type safe method doReturn for this purpose,

@Test
public void testMockitoWithGenerics()
{
    DummyClass dummyClass = Mockito.mock(DummyClass.class);
    List<? extends Number> someList = new ArrayList<Integer>();

    Mockito.doReturn(someList).when(dummyClass).dummyMethod();

    Assert.assertEquals(someList, dummyClass.dummyMethod());
}

as discussed on Mockito's google group.

While this is simpler than thenAnswer, again note that it is not type safe. If you're concerned about type safety, millhouse's answer is correct.

Additional Details

To be clear, here's the observed compiler error,

The method thenReturn(List<capture#1-of ? extends Number>) in the type OngoingStubbing<List<capture#1-of ? extends Number>> is not applicable for the arguments (List<capture#2-of ? extends Number>)

I believe the compiler has assigned the first wildcard type during the when call and then cannot confirm that the second wildcard type in the thenReturn call is the same.

It looks like thenAnswer doesn't run into this issue because it accepts a wildcard type while thenReturn takes a non-wildcard type, which must be captured. From Mockito's OngoingStubbing,

OngoingStubbing<T> thenAnswer(Answer<?> answer);
OngoingStubbing<T> thenReturn(T value);