How to use should_succeed_when_contained_answer_should_succeed method of org.mockito.internal.stubbing.answers.AnswersWithDelayTest class

Just use Mockito.matches(String), for example:

Mockito.verify(mockMyObject).
  myMethod(
    Mockito.matches("(.*apple.*banana.*)|(.*banana.*apple.*)"
  )
);

Mockito can handle chained stubs:

Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

// note that we're stubbing a chain of methods here: getBar().getName()
when(mock.getBar().getName()).thenReturn("deep");

// note that we're chaining method calls: getBar().getName()
assertEquals("deep", mock.getBar().getName());

AFAIK, the first method in the chain returns a mock, which is set up to return your value on the second chained method call.

Mockito's authors note that this should only be used for legacy code. A better thing to do otherwise is to push the behavior into your CacheContext and provide any information it needs to do the job itself. The amount of information you're pulling from CacheContext suggests that your class has feature envy.

Mockito can handle chained stubs:

Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

// note that we're stubbing a chain of methods here: getBar().getName()
when(mock.getBar().getName()).thenReturn("deep");

// note that we're chaining method calls: getBar().getName()
assertEquals("deep", mock.getBar().getName());

AFAIK, the first method in the chain returns a mock, which is set up to return your value on the second chained method call.

Mockito's authors note that this should only be used for legacy code. A better thing to do otherwise is to push the behavior into your CacheContext and provide any information it needs to do the job itself. The amount of information you're pulling from CacheContext suggests that your class has feature envy.

I was intrigued by this post and the comments left by @David so I decided to code a working example for those who follow like me

/*
 * class to test
 */
public class A {

    public void methodA(String str) {
        this.methodB(str);
    }

    protected void methodB(String str) {
        // some implementation
    }
}

We want to assert that the value being passed into methodB() is what we expect. Reading up on the ArgumentCaptor led me to discover the equivalent Captor Annotation

import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.verify;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.ArgumentCaptor;
import org.mockito.Captor;
import org.mockito.Spy;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class MultipleMethodCallTest {

    @Spy
    A a = new A();

    @Captor ArgumentCaptor<String> captor;

    @Test
    public void captureSecondMethodCallArgument() throws Exception {

        // EXPECTED

        String greeting = "hello world";

        // PERFORM TEST

        a.methodA(greeting);

        // ASSERT

        verify(a).methodB(captor.capture());

        assertEquals(greeting, captor.getValue());
    }
}

This example was tested with

• mockito-all-1.8.5.jar
• junit-4.8.2.jar

You may use the following:

model = Mockito.mock(Model.class);
final Map<Foo, List<Bar>> value = new HashMap<Foo, List<Bar>>();

Mockito.when(model.getValue()).thenAnswer(new Answer<Map<Foo, List<Bar>>> () {
  public Map<Foo, List<Bar>> answer(InvocationOnMock invocation) throws Throwable {
    return value;
  }
});

Above can be shortened using lambda as:

Mockito.when(model.getValue()).thenAnswer(invocationOnMock -> value)

It's a defect in Mockito with loading plugins when context class loader is different from which is used to load PowerMock and Mockito.

It could be fixed in Mockito 2, but as it mentioned in comments

Not sure we have the build infrastructure to backport the fix on 1.x

For Mockito 1, fix cannot be delivered, so I fixed in in PowerMock and fix will be include in next PowerMock release (PowerMock 1.6.5).

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
  }
}

Some open source modules include optional java doc jars. To remove them add a configuration mapping to each of your dependencies:

   <dependency org="junit" name="junit" rev="4.8.2" conf="default"/>

The default configuration in ivy is equivalent to the the compile scope in a maven module. This is how the optional libraries can be automatically omitted. (Check their POMs).

A better approach is to declare your own configurations and the default mapping as follows:

<configurations defaultconfmapping="compile->default">
   <conf name="compile" description="Required to compile code"/>
   <conf name="test" description="Additional test dependencies" extends="compile" />
</configurations>

Then in your ivy file you only need to declare the non-standard configurations:

<dependencies>
    <dependency org="org.hamcrest" name="hamcrest-library" rev="1.3.RC2" conf="test->default"/>
    <dependency org="junit" name="junit" rev="4.8.2" conf="test->default"/>
    <dependency org="org.mockito" name="mockito-core" rev="1.8.5" conf="test->default"/>
    <dependency org="javax.persistence" name="persistence-api" rev="1.0"/>
</dependencies>

In this case we only want the 3 test libraries to appear on the test configuration.

Still confused? The magic of ivy configurations is when you use them to manage your build's class path

  <target name='dependencies' description='Resolve project dependencies and set classpaths'>
    <ivy:resolve/>

    <ivy:cachepath pathid="compile.path"  conf="compile"/>
    <ivy:cachepath pathid="test.path"     conf="test"/>
  </target>

This is what Maven is doing when you declare a scope tag on a dependency, for example:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.2</version>
    <scope>test</scope>
</dependency>

The scopes in Maven are fixed. In ivy you can have as many as you need.

You need to have prepared the class calling the constructor, not the class on which the constructor is called, the following should fix you up:

@PrepareForTest(DummyTarget.class)

For more information check this page.