How to use matches_Pattern_matcher_in_subregion method of org.mockitousage.matchers.CustomMatcherDoesYieldCCETest class

There is no WebApplicationContext only an ApplicationContext unless you add the @WebAppConfiguration to your test class.

@ContextConfiguration(locations = { "classpath:/test/BeanConfig.xml" })
@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
public class CandidateControllerTest { ... }

Instead of the @RunWith annotation you can also extend one of springs convenience classes.

@ContextConfiguration(locations = { "classpath:/test/BeanConfig.xml" })
@WebAppConfiguration
public class CandidateControllerTest extends AbstractJUnit4SpringContextTests { ... }

Links

1. WebAppConfiguration javadoc
2. Reference Guide

Since you are loading configuration class MyApplication.class datasource bean will be created, Try moving datasource in another bean which is not used in a test, make sure all classes loaded for tests are not dependant on datasource.
Or
In your tests create a config class marked with @TestConfiguration and include it in SpringBootTest(classes=TestConfig.class) mocking data source there like

@Bean
public DataSource dataSource() {
    return Mockito.mock(DataSource.class);
}

But this may fail since method call to this mocked datasouce for connection will return null, In that case, you'll have to create an in-memory datasource and then mock jdbcTemplate and rest of dependencies.

I had this problem today. It is caused by calls to the mock to set up stubbing actually consuming the stubbing already in place.

In this example, change the first line to

when(mock.call(anyString())).thenReturn("","",string1,string2)

This will give you two blank responses when you set up your other mock returns, leaving string1 as the first useful return value.

Try also the doReturn alternative which I think may not have these issues:

doReturn(string1,string2).when(mock).call(anyString());

This uses the stub differently during setup.

So I did some more research on this. Here's the function I was playing with, based on the OP's question:

    Function<String, String> function = mock(Function.class);
    when(function.apply(anyString())).thenReturn("A","B","C");
    when(function.apply("Jim")).thenReturn("Jim");
    when(function.apply("Bob")).thenReturn("Bob");

    assertThat(function.apply("Jim")).isEqualTo("Jim");
    assertThat(function.apply("Bob")).isEqualTo("Bob");
    assertThat(function.apply("")).isEqualTo("A");
    assertThat(function.apply("")).isEqualTo("B");
    assertThat(function.apply("")).isEqualTo("C");
    assertThat(function.apply("")).isEqualTo("C");

The above fails at isEqualTo("A") because the two calls to set up the mocks for Jim and Bob consume return values from the list provided to anyString().

You might be tempted to reorder the when clauses, but that fails, because the anyString() supersedes the special cases, so that fails too.

The following version of the above DOES work as expected:

    when(function.apply(anyString())).thenReturn("A","B","C");

    doReturn("Jim")
        .when(function)
        .apply("Jim");
    doReturn("Bob")
        .when(function)
        .apply("Bob");

    assertThat(function.apply("Jim")).isEqualTo("Jim");
    assertThat(function.apply("Bob")).isEqualTo("Bob");
    assertThat(function.apply("")).isEqualTo("A");
    assertThat(function.apply("")).isEqualTo("B");
    assertThat(function.apply("")).isEqualTo("C");
    assertThat(function.apply("")).isEqualTo("C");

This is because the doReturn technique, which is intended for modifying pre-existing mocks in flight, doesn't actually involve calling the method on the mock to set up the mocking.

You could use doReturn for all setup, rather than mixing between when...thenReturn and doReturn..when..function(). As it happens, that's a bit uglier:

    doReturn("A").doReturn("B").doReturn("C")
        .when(function)
        .apply(anyString());

There's no convenient varargs function to let you specify multiple returns in sequence. The above has been tested and does work, though.

I would avoid it. Generally speaking, you should structure things as best you can to avoid needing to test private variables and stick with the interactions that the rest of the application will be exposed to. This is typically public methods/properties and protected methods by using fakes/doubles.

The purpose of the unit tests are to verify how the object under test is interacted with, not necessarily it's implementation details. Basically, with input x, I should get output/effect y. If you get hung up on testing exactly how x produces y, you run the risk of making your classes inflexible to change. Every refactor of your class is likely to break your tests, even if the output and end result is the same.

Here's what I've been doing to cope with the situation.

I use global imports on a new test class.

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;
import static org.mockito.Matchers.*;

When you are finished writing your test and need to commit, you just CTRL+SHIFT+O to organize the packages. For example, you may just be left with:

import static org.mockito.Mockito.doThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
import static org.mockito.Matchers.anyString;

This allows you to code away without getting 'stuck' trying to find the correct package to import.

It should be enough to name your mocks serviceA and serviceB. From Mockito documentation:

Property setter injection; mocks will first be resolved by type, then, if there is several property of the same type, by the match of the property name and the mock name.

In your example:

@InjectMocks ServiceCaller classUnderTest;

@Mock SomeService serviceA;
@Mock SomeService serviceB;

Note that it is not necessary to manually create class instance when using @InjectMocks.

Nevertheless I personally prefer injecting dependencies using constructor. It makes it easier to inject mocks in tests (just call a constructor with your mocks - without reflections tools or @InjectMocks (which is useful, but hides some aspects)). In addition using TDD it is clearly visible what dependencies are needed for the tested class and also IDE can generate your constructor stubs.

Spring Framework completely supports constructor injection:

@Bean
public class ServiceCaller {
    private final SomeService serviceA;
    private final SomeService serviceB;

    @Autowired
    public ServiceCaller(@Qualifier("serviceA") SomeService serviceA,
                         @Qualifier("serviceB") SomeService serviceB) { ... }

    ...
}

This code can be tested with:

@Mock SomeService serviceA;
@Mock SomeService serviceB;

//in a setup or test method
ServiceCaller classUnderTest = new ServiceCaller(serviceA, serviceB); 

It is very likely that the Runnable hasn't been executed yet by the asyncTaskExecutor when you verify the invocation, resulting in a verification error in your unit test.

The best way to fix this is to join on the generated thread and wait for execution before verifying the invocations.

If you cannot get the instance of the thread, a possible work around is to mock the asyncTaskExecutor and implement it so it will execute the runnable directly.

private ExecutorService executor;

@Before
public void setup() {
    executor = mock(ExecutorService.class);
    implementAsDirectExecutor(executor);
}

protected void implementAsDirectExecutor(ExecutorService executor) {
    doAnswer(new Answer<Object>() {
        public Object answer(InvocationOnMock invocation) throws Exception {
            ((Runnable) invocation.getArguments()[0]).run();
            return null;
        }
    }).when(executor).submit(any(Runnable.class));
}

What is wrong?

Well, the problem here is quite subtle, when you call Mockito.spy(p), mockito creates behind the scene some kind of decorator over your instance of ClassWithInnerObject allowing to monitor all methods calls on your instance. Thanks to that, you can check how many times a given method has been called but on the decorator only not on your instance. And here, when you use an inner class, it calls innerFunc() on your instance of ClassWithInnerObject not on the decorator so for Mockito innerFunc() has not been called.

You need to provide a way of accessing the member variables so you can pass in a mock (the most common ways would be a setter method or a constructor which takes a parameter).

If your code doesn't provide a way of doing this, it's incorrectly factored for TDD (Test Driven Development).