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

As this link you posted indicates, you've encountered a bug with Answers.RETURNS_DEEP_STUBS.

I don't actually see any reason to actually use RETURNS_DEEP_STUBS in your example code. You really should try to evaluate whether or not you need deep stubs, because, as the Mockito docs say, "every time a mock returns a mock a fairy dies." So if you can, just take that out and your example will work.

However, if you insist on using deep stubs, you can hack around this error by up-casting the return value from the method call to Object. For example, replace the offending line in your code with this:

when((Object)bList.get(0)).thenReturn(b);

All that being said, I personally agree with @jhericks. The best solution is probably to use an actual ArrayList which contains your mock as opposed to mocking List. The only problem is getting your list injected, so you'd have to use @Spy. For example:

@RunWith(MockitoJUnitRunner.class)
class ATest{
  private B b = mock(B.class);
  @Spy
  private List<B> bList = new ArrayList<B>() {{ add(b); }};

  @InjectMocks
  private C c = new C();

  @Test
  public void test(){
    c.methodIWantToTest();
    // verify results
  }
}

When you are invoking

Mockito.when(spy.isCertainValue()).thenReturn(true);

the method isCertainValue() is getting called here. This is how Java works: to evaluate the argument of Mockito.when, the result of spy.isCertainValue() must be evaluated so the method must be called.

If you don't want that to happen, you can use the following construct:

Mockito.doReturn(true).when(spy).isCertainValue();

This will have the same mocking effect but the method won't be called with this.

The thenReturn() method signature is

thenReturn(T value, T... values)

So it takes an instance of T, followed by a vararg T..., which is syntactic sugar for an array. So you can use

when(foo.bar()).thenReturn(list.get(0), 
                           list.subList(1, list.size()).toArray(new Foo[]{}));

But a cleaner solution would be to create an Answer implementation that takes a List as argument and answers the next element of the list every time it's used. And then use

when(foo.bar()).thenAnswer(new SequenceAnswer<>(list));

For example:

private static class SequenceAnswer<T> implements Answer<T> {

    private Iterator<T> resultIterator;

    // the last element is always returned once the iterator is exhausted, as with thenReturn()
    private T last;

    public SequenceAnswer(List<T> results) {
        this.resultIterator = results.iterator();
        this.last = results.get(results.size() - 1);
    }

    @Override
    public T answer(InvocationOnMock invocation) throws Throwable {
        if (resultIterator.hasNext()) {
            return resultIterator.next();
        }
        return last;
    }
}

I'll refer your sentence:

So let's say I introduce a new feature and want to test for bugs. I use mvn test form the command line. Then all the test are run but i think it will take ages for a real application with a lot of tests.

This question you raise here is very important, so I'll try to provide an architectural point of view here without delving into technical implementation.

There are many different kinds of tests. What you're referring to is called an integration test, and not a unit test. The difference between those two that in unit tests you're testing one class and all the rest should be mocked (there are frameworks like EasyMock or Mockito for this).

Unit test has a lot of restrictions:

• You cannot access any external components (web servers, db and so forth)
• Unit tests run only in memory
• They are extremely fast (particle of second).

These tests are very helpful when it comes to testing the functionality of your classes

Now when the development of the feature is done, its time to test that the feature works in "semi-real" environment. Usually when running those, there is a database available as well as spring container. For running this kind of tests you can use spring tests extensions and use different techniques (for example, substitute one the whole application spring context with a "partial" context or override some beans with stubs or something.

Now, this difference is interesting in the context of your question because there should be many unit tests and substantially less integration tests in the application. So if you can cover something you've written with unit tests - write unit tests. It's incredibly fast by nature and you can run a lot of those (thousands) in no-time. Only if you (rarely) cannot cover your functionality in unit tests - write the integration test. This will typically relevant for code that runs against the DB for example and you would like to test whether the queries produced by the component are really valid.

So generally if you have both types of tests you should be covered and there should be not so many integration tests, so running those shouldn't be a real hassle.

If you want to mock the return result of motherFunction then you need not worry about the internal implementation of the method (which ends up calling functionVoid). What you do need to do is provide Mockito with an instruction as to what to do when the method, motherFunction is invoked, this can be achieved via the when clause with syntax;

    when(mockedObject.motherFunction()).thenReturn("Any old string");

If that misses the point of what you are attempting to achieve then look at how to mock void methods in the documentation and determine whether the use of doAnswer is applicable here, something like;

doAnswer(new Answer<Void>() {

  @Override
  public Void answer(InvocationOnMock invocation) throws Throwable {
    String output_value = invocation.getArguments()[0];
    output_value = "Not blank";
    return null;
  }
}).when(myClass2).functionVoid(anyString());

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.

Akka has a class AutoPilot that is basically a general mock for actors, with the ability to respond to messages and assert that messages were sent. http://doc.akka.io/docs/akka/snapshot/java/testing.html

Here's the java example for that page. You create a probe, set an auto-pilot that can respond to messages, and get an ActorRef from it that you can substitute in for your real actor.

new JavaTestKit(system) {{
  final JavaTestKit probe = new JavaTestKit(system);
  // install auto-pilot
  probe.setAutoPilot(new TestActor.AutoPilot() {
    public AutoPilot run(ActorRef sender, Object msg) {
      sender.tell(msg, ActorRef.noSender());
      return noAutoPilot();
    }
  });
  // first one is replied to directly ...
  probe.getRef().tell("hello", getRef());
  expectMsgEquals("hello");
  // ... but then the auto-pilot switched itself off
  probe.getRef().tell("world", getRef());
  expectNoMsg();
}};

Even more meaningful :

import static org.mockito.Mockito.never;
import static org.mockito.Mockito.verify;

// ...

verify(dependency, never()).someMethod();

The documentation of this feature is there §4 "Verifying exact number of invocations / at least x / never", and the never javadoc is here.

For some reason, your test suite, tries to load the MockitoJunitRunner from the org.mockito.junit contained in the Mockito versions >= 2. O. In that version, the line:

at org.mockito.junit.MockitoJUnitRunner.<init>(MockitoJUnitRunner.java:152)

is doing this:

public MockitoJUnitRunner(Class<?> klass) throws InvocationTargetException {
        //by default, StrictRunner is used. We can change that potentially based on feedback from users
        this(new StrictRunner(new RunnerFactory().createStrict(klass), klass));
    }

and the RunnerFactory that is loaded here is from version 1.x as createStrict has been introduced in Mockito 2.x.

So go through the pom dependency tree and to find what artifact implicitly add the Mockito 2.x dependency to your project and exclude it.

Alternatively.. as a workaround, instead of the @RunWith(MockitoJUnitRunner.class) you can use:

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

You can also check out this Mockito cheat sheet to keep all the standards at hand.