How to use knows_if_mock_is_lenient method of org.mockitousage.strictness.StrictnessPerMockTest class

You need to inject the mock into the class which you are testing. You do not need access to Subscriber. The way mockito and other mocking frameworks help is that you do not need access to objects which you are interacting with. You do however need a way to get mock objects into the class you are testing.

public class WebAdaptor {

    public WebAdaptor(Subscriber subscriber) { /* Added a new constructor */
       this.subscriber = subscriber;
    }

    private Subscriber subscriber;

    public void run() {
        subscriber.init();
    }
}

Now you can verify your interactions on the mock, rather than on the real object.

@Test
public void runShouldInvokeSubscriberInit() {

    // Given
    Subscriber mockSubscriber = mock(Subscriber.class);
    WebAdaptor adaptor = new WebAdaptor(mockSubscriber);  // Use the new constructor

    // When
    adaptor.run();

    // Then
    verify(mockSubscriber).init();
}

If adding the Subscriber to the constructor is not the correct approach, you could also consider using a factory to allow WebAdaptor to instantiate new Subscriber objects from a factory which you control. You could then mock the factory to provider mock Subscribers.

Even though TestRoute is a subtype of RouteDefinition, a IHandleRoute<TestRoute> is not a subtype of IHandleRoute<RouteDefinition>.

The when method from Mockito returns an object of type OngoingStubbing<IHandleRoute<RouteDefinition>>. This is due to the compiler inferring the type parameter TRoute from the method

<TRoute extends RouteDefinition> IHandleRoute<TRoute> getHandlerFor(TRoute route);

to be RouteDefinition since the argument passed to getHandlerFor is declared of type RouteDefinition.

On the other hand, the thenReturn method is given an argument of type IHandleRoute<TestRoute> whereas it expects an IHandleRoute<RouteDefinition>, that is the type argument of the OngoingStubbing mentioned earlier. Hence the compiler error.

To solve this, the simplest way is probably to change the declaration type of route to be TestRoute:

TestRoute route = new TestRoute();

IRouteHandlerRegistry registry = mock(IRouteHandlerRegistry.class);
IHandleRoute<TestRoute> handler = mock(IHandleRoute.class);

when(registry.getHandlerFor(route)).thenReturn(handler);

MockitoJUnitRunner gives you automatic validation of framework usage, as well as an automatic initMocks().

The automatic validation of framework usage is actually worth having. It gives you better reporting if you make one of these mistakes.

• You call the static when method, but don't complete the stubbing with a matching thenReturn, thenThrow or then. (Error 1 in the code below)

• You call verify on a mock, but forget to provide the method call that you are trying to verify. (Error 2 in the code below)

• You call the when method after doReturn, doThrow or doAnswer and pass a mock, but forget to provide the method that you are trying to stub. (Error 3 in the code below)

If you don't have validation of framework usage, these mistakes are not reported until the following call to a Mockito method. This might be

• in the same test method (like error 1 below),
• in the next test method (like error 2 below),
• in the next test class.

If they occur in the last test that you run (like error 3 below), they won't be reported at all.

Here's how each of those types of errors might look. Assume here that JUnit runs these tests in the order they're listed here.

@Test
public void test1() {

    // ERROR 1
    // This compiles and runs, but it's an invalid use of the framework because 
    // Mockito is still waiting to find out what it should do when myMethod is called.
    // But Mockito can't report it yet, because the call to thenReturn might 
    // be yet to happen.
    when(myMock.method1());

    doSomeTestingStuff();

    // ERROR 1 is reported on the following line, even though it's not the line with
    // the error.
    verify(myMock).method2();

}

@Test
public void test2() {

    doSomeTestingStuff();

    // ERROR 2
    // This compiles and runs, but it's an invalid use of the framework because
    // Mockito doesn't know what method call to verify.  But Mockito can't report 
    // it yet, because the call to the method that's being verified might 
    // be yet to happen.
    verify(myMock);
}

@Test
public void test3() {

    // ERROR 2 is reported on the following line, even though it's not even in 
    // the same test as the error.
    doReturn("Hello").when(myMock).method1();


    // ERROR 3
    // This compiles and runs, but it's an invalid use of the framework because
    // Mockito doesn't know what method call is being stubbed.  But Mockito can't 
    // report it yet, because the call to the method that's being stubbed might 
    // be yet to happen.

    doReturn("World").when(myMock);

    doSomeTestingStuff(); 

    //  ERROR 3 is never reported, because there are no more Mockito calls. 
}

Now when I first wrote this answer more than five years ago, I wrote

So I would recommend the use of the MockitoJUnitRunner wherever possible. However, as Tomasz Nurkiewicz has correctly pointed out, you can't use it if you need another JUnit runner, such as the Spring one.

My recommendation has now changed. The Mockito team have added a new feature since I first wrote this answer. It's a JUnit rule, which performs exactly the same function as the MockitoJUnitRunner. But it's better, because it doesn't preclude the use of other runners.

Include

@Rule 
public MockitoRule rule = MockitoJUnit.rule();

in your test class. This initialises the mocks, and automates the framework validation; just like MockitoJUnitRunner does. But now, you can use SpringJUnit4ClassRunner or any other JUnitRunner as well. From Mockito 2.1.0 onwards, there are additional options that control exactly what kind of problems get reported.

So I was actually able to solve my problem. The trick is to manually create your own MockRestServiceServerBuilder to build your MockRestServiceServer instead of using the createServer(RestTemplate) or bindTo(RestTemplate).build() methods, like so:

MockRestServiceServer.MockRestServiceServerBuilder builder = 
    MockRestServiceServer.bindTo(restTemplate);
builder.ignoreExpectOrder(true);
MockRestServiceServer server = builder.build();

By doing so, the underlying RequestExpectationManager field in the MockRestServiceServer is initialized as an UnorderedRequestExpectationManager, allowing you to match requests regardless of the order in which they were made. This solved a lot of headaches for me.

You cannot return anyString(), which is a matcher. It has to be a real string instance, like "foo".

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).

I created the following Answer implementation:

public class CapturingAnswer<T, R> implements Answer<T> {

    private final Function<InvocationOnMock, R> capturingFunction;

    private final List<R> capturedValues = new ArrayList<R>();

    public CapturingAnswer(final Function<InvocationOnMock, R> capturingFunction) {
        super();
        this.capturingFunction = capturingFunction;
    }

    @Override
    public T answer(final InvocationOnMock invocation) throws Throwable {
        capturedValues.add(capturingFunction.apply(invocation));
        return null;
    }

    public List<R> getCapturedValues() {
        return Collections.unmodifiableList(capturedValues);
    }

}

This answer captures properties of the invocations being made. The capturedValues can then be used for simple assertions. The implementation uses Java 8 API. If that is not available one would need to use an interface that is able to convert the InvocationOnMock to the captured value. The usage in the testcase is like this:

@Test
public void testSomething() {
    CapturingAnswer<Void,Date> captureDates = new CapturingAnswer<>(this::getEntityDate)
    Mockito.doAnswer(captureDates).when(persistence).save(Mockito.any(Entity.class));

    service.foo();

    Assert.assertNull(captureDates.getCapturedValues().get(0));
}

private Date getEntityDate(InvocationOnMock invocation) {
    Entity entity = (Entity)invocation.getArguments()[0];
    return entity.getDate();
}

The capturing that is done by the presented Answer implementation can't be achieved with Mockitos ArgumentCaptor because this is only used after the invocation of the method under test.

This is a perfect example for making functions more testable. This function takes no input and produces no output, affecting the world only via side effect, making it completely untestable through standard means.

To refactor this function to make it more testable:

• Don't ask the user for input via scanner, take the user's input as an input parameter.
• Don't print the result, return it.

The caller of the function can then decide how to provide the inputs and what to do with the output. Your modified program can ask for user input, call the function, then print the output. A testing framework can supply the input from a list of inputs to test, and check the outputs against the expected values.

According to https://groups.google.com/forum/?fromgroups#!topic/mockito/9WUvkhZUy90, you should rephrase your

when(bar.getFoo()).thenReturn(fooBar)

to

doReturn(fooBar).when(bar).getFoo()