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

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

A POST request normally passes its param in its body. So I cannot understand what you expect by giving both a param and a content for same request.

So here, you can simply do:

    mockMvc.perform(
        post("/usermgmt/createCloudCredential").contentType(
            MediaType.APPLICATION_JSON).content(json)).andExpect(
        status().isOk());

If you need to pass the parameter "username=aricloud_admin", add it to the JSON string, or alternatively, pass it explicitly as a query string:

    mockMvc.perform(
        post("/usermgmt/createCloudCredential?username=aricloud_admin")
            .contentType(MediaType.APPLICATION_JSON).content(json))
            .andExpect(status().isOk());

You can use PowerMockito along with Mockito to mock static methods:

@RunWith(PowerMockRunner.class)
@PrepareForTest(ServiceLoader.class)
public class PowerMockingStaticTest
{
    @Mock
    private ServiceLoader mockServiceLoader;

    @Before
    public void setUp()
    {
        PowerMockito.mockStatic(ServiceLoader.class);
        Mockito.when(ServiceLoader.load(Mockito.any(Class.class))).thenReturn(mockServiceLoader);
    }

    @Test
    public void test()
    {
        Assert.assertEquals(mockServiceLoader, ServiceLoader.load(Object.class));
    }
}

You could extract a method for doing the actual reading and then test that instead. That would mean you only have to mock a single reader. For example, your code would be something like this:

public void aMethod(){
    File f = map.get("key1")
    BuffereReader r = new BufferedReader(new FileReader(f));
    readStuff(r);
}

public void readStuff(BufferedReader r){
    String line=null;
    do {
        line=r.readLine();
    } while(r!=null);
}

then your test code would be more like the following:

BufferedReader bufferedReader = Mockito.mock(BufferedReader.class);
Mockito.when(bufferedReader.readLine()).thenReturn("line1", "line2", "line3");
objUnderTest.readStuff(bufferedReader);
//verify result

how about you create an anonymous exception of type JsonProcessingException

when(mapper.writeValueAsString(any(Object.class))).thenThrow(new JsonProcessingException("Error"){});

The {} braces does the trick. This is much better since it is not confusing to the reader of the test code.

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.

First, I would split your test into 2 separate tests, because you are testing 2 quite different scenarios:

@Test
public void testSuccessfulLogin() throws Exception {
    RequestBuilder requestBuilder = formLogin().user("test@tester.de").password("test");
    mockMvc.perform(requestBuilder).andExpect(redirectedUrl("/home")).andExpect(status().isFound());
}

@Test
public void testHomepageThrows500() throws Exception {

    // configure a mock service in the controller to throw an exception

    RequestBuilder requestBuilder = formLogin().user("test@tester.de").password("test");
    mockMvc.perform(requestBuilder).andExpect(redirectedUrl("/home")).andExpect(status().is5xxServerError());
}

Your first test is that of the successful login scenario.

The second test, as you've worded it in your question, is that where the home page (assuming a controller) returns a HTTP 500.
To get to the home page, you still need to login - it's not the act of logging on that generates the error, its the controller itself once you've logged on.
To make the controller return a HTTP 500 you are going to need to simulate some error. Without seeing your controller, I can only guess there is some service that is injected in. In your test you should be able to provide a mock of that, and then configure the mock to throw an exception.

You should be able to inject a mock something like this:

@RunWith(SpringJUnit4ClassRunner.class)
@WebMvcTest(HomeController.class)
public class HomeControllerIntegrationTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private YourService yourService;

And then within your test do something like the following (I'm using the BDD methods of mockito):

@Test
public void testHomepageThrows500() throws Exception {

    given(yourService.someMethod()).willThrow(new Exception("something bad happened");

    RequestBuilder requestBuilder = formLogin().user("test@tester.de").password("test");
    mockMvc.perform(requestBuilder).andExpect(redirectedUrl("/home")).andExpect(status().is5xxServerError());
}

An alternative to ArgumentMatcher is ArgumentCaptor.

Official example:

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());

A captor can also be defined using the @Captor annotation:

@Captor ArgumentCaptor<Person> captor;
//... MockitoAnnotations.initMocks(this);
@Test public void test() {
    //...
    verify(mock).doSomething(captor.capture());
    assertEquals("John", captor.getValue().getName());
}

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.