List of Classes and Methods of org.mockito.invocation package of Mockito Framework

Iterator mockIterator = mock(Iterator.class);
doCallRealMethod().when(fruits).forEach(any(Consumer.class));
when(fruits.iterator()).thenReturn(mockIterator);
when(mockIterator.hasNext()).thenReturn(true, false);
when(mockIterator.next()).thenReturn(mockObject);

Use @Spy annotation

@RunWith(MockitoJUnitRunner.class)
public class DemoTest {
    @Spy
    private SomeService service = new RealServiceImpl();

    @InjectMocks
    private Demo demo;

    /* ... */
}

Mockito will consider all fields having @Mock or @Spy annotation as potential candidates to be injected into the instance annotated with @InjectMocks annotation. In the above case 'RealServiceImpl' instance will get injected into the 'demo'

For more details refer

Mockito-home

@Spy

@Mock

This should work

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.verify;

verify(bar).DoStuff(any(Foo[].class));

Inlining code can sometimes be confusing. Let's unwrap the second block of code:

A source = mock(A.class);
final List<String> documents = getList();
final Iterator<String> iter = getList().iterator()
when(source.iterator()).thenReturn(iter);

Now, it's easier to understand. The same iter object is always returned, and hence it retains it's state. The fact that before the change above mockito had a function call in the brackets is inconsequential - mockito has an object passed to it, which it stores internally, and returns when required. It cannot "remember" that this object was produced by calling a function unless it has the actual code to execute it - for example, like you did in the first snippet.

You need to move @EnableJpaAuditing annotation to a separate @Configuration class otherwise it will be loaded even for unrelated application slices.

@Configuration
@EnableJpaAuditing
public class JpaAuditingConfiguration {}

@SpringBootApplication class is used as default configuration for all tests with slices so any additional configuration glued to it will affect more tests than you would expect.

This is also well explained in documentation: User Configuration and Slicing

If you're able to refactor your code, you can wrap your calls to the final/static methods in simple instance methods, for example:

protected Foo doBar(String name) {
    return Utility.doBar(name);
}

This allows you to override your wrapper method in the unit test to return a mock instance of Foo.

Alternatively you can use Powermock, which extends Easymock (and Mockito) to allow mocking of final and static methods:

PowerMock is a framework that extend other mock libraries such as EasyMock with more powerful capabilities. PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more.

Here's an example test mocking a static final method, the example shows how to mock some other types too:

@Test
public void testMockStaticFinal() throws Exception {
    mockStatic(StaticService.class);
    String expected = "Hello altered World";
    expect(StaticService.sayFinal("hello")).andReturn("Hello altered World");
    replay(StaticService.class);

    String actual = StaticService.sayFinal("hello");

    verify(StaticService.class);
    assertEquals("Expected and actual did not match", expected, actual);

    // Singleton still be mocked by now.
    try {
        StaticService.sayFinal("world");
            fail("Should throw AssertionError!");
    } catch (AssertionError e) {
        assertEquals("\n  Unexpected method call sayFinal(\"world\"):", 
            e.getMessage());
    }
}

The implementation is the unit that needs to be tested. That is of course what you are instantiating and what contains the program/business logic.

If you had a critical interface and you wanted to make sure every implementation adhered to it properly, then you may write a test suite that focuses on the interface and requires an instance be passed in (agnostic of any implementation type).

Yes, it would probably be easier to use Mockito for PrintStream, it may not always be possible to avoid using a mock object like you did in this specific example.

The best solution I have found is to reverse the order of the stubs:

Map<String, String> map = mock(Map.class);
when(map.get(anyString())).thenReturn("I don't know that string");
when(map.get("abcd")).thenReturn("defg");
when(map.get("defg")).thenReturn("ghij");

When the default is to throw an exception you can just use doThrow and doReturn

doThrow(new RuntimeException()).when(map).get(anyString());
doReturn("defg").when(map).get("abcd");
doReturn("ghij").when(map).get("defg");

https://static.javadoc.io/org.mockito/mockito-core/2.18.3/org/mockito/Mockito.html#12

So I quickly put something together to see if I could find your issue, and can't below is my sample code using the any(Class) matcher and it worked. So there is something we are not seeing.

Test case

@RunWith(MockitoJUnitRunner.class)
public class ClientTest
{
    @Test
    public void test()
    {
        Client client = Mockito.mock(Client.class);

        Mockito.when(client.batchCall(Mockito.any(Request[].class))).thenReturn("");

        Request[] requests = {
            new Request(), new Request()};

        Assert.assertEquals("", client.batchCall(requests));
        Mockito.verify(client, Mockito.times(1)).batchCall(Mockito.any(Request[].class));
    }
}

client class

public class Client
{
    public String batchCall(Request[] args)
    {
        return "";
    }
}

Request Class

public class Request
{

}