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

I think what you want is:

VendorObject vo = mock(VendorObject.class, new Answer() {
    @Override
    public Object answer(InvocationOnMock invocation) {

        // 1. Check if method exists on RedirectToObject.
        // 2a. If it does, call the method with the args and return the
        // result.
        // 2b. If it does not, throw an exception to fail the unit test.

    }
});

Of course, if you want to use this approach frequently, no need for the Answer to be anonymous.

From the documentation: "It's quite advanced feature and typically you don't need it to write decent tests. However it can be helpful when working with legacy systems." Sounds like you.

It appears Mockito uses an algorithm described in their JavaDoc

If I understand correctly, it will first sort on type (in this case only 1 B) and then sort on name (no changes here). It will finally inject using the OngoingInjector interface implementation, which appears to search for the first field and inject it.

Since you only have 1 B defined and there are 2 fields of B in the Mock, it will see the match of the first instance to the field and stop. This is because mocks.size() == 1 in NameBasedCandidateFilter . Therefore it will stop filtering and inject it directly. If you create multiple mocks of the same type, they will get sorted on Name and injected accordingly.

I was able to get it work when I created multiple mocks (but less than the number of fields) of a specific type.

@RunWith(MockitoJUnitRunner.class)
public class MockitoTest {

    @Mock(name = "b2")
    private B b2;

    @Mock(name = "b3")
    private B b3;

    @InjectMocks
    private A a;

    @Test
    public void testInjection() {
        System.out.println(this.a);
    }

    static class A {

        private B b1;

        private B b2;

        private B b3;
    }

    interface B {
    }
}

This will correctly inject b2 into a.b2 and b3 into a.b3 instead of a.b1 and a.b2 (the first 2 fields that are defined in A).

You can always leave a GitHub issue on their repository with an enhancement or change on the injection filtering algorithm in order to be looked at.

You can use a spy on your static class and mock only specific methods:

@RunWith(PowerMockRunner.class)
@PrepareForTest(MyStaticTest.MyStaticClass.class)
public class MyStaticTest {

public static class MyStaticClass {
    public static String getA(String a) {
        return a;
    }
    public static String getB(String b) {
        return b;
    }
}

@Test
public void should_partial_mock_static_class() throws Exception {
    //given
    PowerMockito.spy(MyStaticClass.class);
    given(MyStaticClass.getB(Mockito.anyString())).willReturn("B");
    //then
    assertEquals("A", MyStaticClass.getA("A"));
    assertEquals("B", MyStaticClass.getA("B"));
    assertEquals("C", MyStaticClass.getA("C"));
    assertEquals("B", MyStaticClass.getB("A"));
    assertEquals("B", MyStaticClass.getB("B"));
    assertEquals("B", MyStaticClass.getB("C"));
}

}

Mockito 2 now supports final classes and methods!

But for now that's an "incubating" feature. It requires some steps to activate it which are described in What's New in Mockito 2:

Mocking of final classes and methods is an incubating, opt-in feature. It uses a combination of Java agent instrumentation and subclassing in order to enable mockability of these types. As this works differently to our current mechanism and this one has different limitations and as we want to gather experience and user feedback, this feature had to be explicitly activated to be available ; it can be done via the mockito extension mechanism by creating the file src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker containing a single line:

mock-maker-inline

After you created this file, Mockito will automatically use this new engine and one can do :

 final class FinalClass {
   final String finalMethod() { return "something"; }
 }

 FinalClass concrete = new FinalClass(); 

 FinalClass mock = mock(FinalClass.class);
 given(mock.finalMethod()).willReturn("not anymore");

 assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());

In subsequent milestones, the team will bring a programmatic way of using this feature. We will identify and provide support for all unmockable scenarios. Stay tuned and please let us know what you think of this feature!

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

this one did the trick

@Test
void willReturnTheInjectedUUIDValueTest() {

    UUID uuid = UUID.randomUUID();
    Gateway gateway = Mockito.mock(Gateway.class);

    doAnswer(ans -> {
        Consumer<UUID> callback = (Consumer<UUID>) ans.getArgument(1);
        callback.accept(uuid);
        return null;
    }).when(gateway).process(Mockito.any(String.class), Mockito.any(Consumer.class));

    Interactor.builder().gateway(gateway).build().process("ignored", s -> {
        Assertions.assertEquals(uuid.toString(), s);
    });
}

This answer was the hint -> https://stackoverflow.com/a/47226374/148397

Here is the solution to the above mentioned scenario. As I was not interested in testing the invocation of newTransactionTemplate.execute(), it being an spring API. I wanted to test the invocation of reserveService.callReserve(reserveDetails) and reserveService.callRelease(id). The only way to test this is if we create a transactiontemplate/transactioncallback "real" implementation/stub that is just pass thru. so the doIntransaction method should do nothing more than execute the action. then we can set expectation on the action methods which in this case is the reserveService.

    when(mockTransactionTemplate.execute(Mockito.<TransactionCallback>any())).thenAnswer(new Answer() {
         public Object answer(InvocationOnMock invocation) {
             Object[] args = invocation.getArguments();
           TransactionCallback arg = (TransactionCallback)args[0];
             return arg.doInTransaction(new SimpleTransactionStatus());
         }
     });     
    when(mockResourceService.callReserve(any(ReserveDetails.class))).thenReturn(reserveInfo);
    when(mockResourceService.callRelease(eq(id))).thenReturn(releaseInfo);

    //Call the exe method
    someService.exe();

    verify(mockResourceService, times(1)).callReserve(any(ReserveDetails.class));
    verify(mockSomeOtherService, times(1)).doSomthing());
    verify(mockMemberResourceService, times(1)).callRelease(eq(id)); 

According to the Mockito_Maven page on the PowerMock wiki, use this:

<properties>
    <powermock.version>1.6.6</powermock.version>
</properties>
<dependencies>
   <dependency>
      <groupId>org.powermock</groupId>
      <artifactId>powermock-module-junit4</artifactId>
      <version>${powermock.version}</version>
      <scope>test</scope>
   </dependency>
   <dependency>
      <groupId>org.powermock</groupId>
      <artifactId>powermock-api-mockito</artifactId>
      <version>${powermock.version}</version>
      <scope>test</scope>
   </dependency>
</dependencies>

powermock-api-support seems to be "utility classes only", where you still need the core libraries provided in powermock-module-junit4.

Technically speaking both "mocks" and "spies" are a special kind of "test doubles".

Mockito is unfortunately making the distinction weird.

A mock in mockito is a normal mock in other mocking frameworks (allows you to stub invocations; that is, return specific values out of method calls).

A spy in mockito is a partial mock in other mocking frameworks (part of the object will be mocked and part will use real method invocations).