How to use shouldReportTooFewInvocations method of org.mockito.internal.verification.checkers.NumberOfInvocationsInOrderCheckerTest class

First, you can't prevent people from messing with your game by declaring things 'final'. There are reflection tricks and whole code generation libraries that make it merely slightly inconvenient to get past this.

So, lose the finals, and then you can use jmock or whatever library you like to make mocks.

You need to inject mock inside the class you're testing. At the moment you're interacting with the real object, not with the mock one. You can fix the code in a following way:

void testAbc(){
     myClass.myObj = myInteface;
     myClass.abc();
     verify(myInterface).myMethodToBeVerified(new String("a"), new String("b"));
}

although it would be a wiser choice to extract all initialization code into @Before

@Before
void setUp(){
     myClass = new myClass();
     myClass.myObj = myInteface;
}

@Test
void testAbc(){
     myClass.abc();
     verify(myInterface).myMethodToBeVerified(new String("a"), new String("b"));
}

@Mock

Used to make Mockito create a mock object.

@InjectMock

When you want Mockito to create an instance of an object and use the mocks annotated with @Mock as its dependencies.

@AutoWired

Used when you want to autowire a bean from the spring context, works exactly the same as in normal code but can only be used in tests that actually creates an application context, such as tests annotated with @WebMvcTest or @SpringBootTest.

@MockBean

Can be used to add mock objects to the Spring application context. The mock will replace any existing bean of the same type in the application context. If no bean of the same type is defined, a new one will be added. Often used together with @SpringBootTest

So normally you either:

• Use @Mock and @InjectMocks for running tests without a spring context, this is preferred as it's much faster.
• Use @SpringBootTest or @SpringMvcTest to start a spring context together with @MockBean to create mock objects and @Autowired to get an instance of class you want to test, the mockeans will be used for its autowired dependencies. You use this when writing integration tests for code that interact with a database or want to test your REST API.

I also faced the same problem.

And finally, I found argThat() will return null, and normally the argument in the function in kotlin, does not accept null type.

The source code of argThat from ArgumentMatchers.java

public static <T> T argThat(ArgumentMatcher<T> matcher) {
    reportMatcher(matcher);
    return null;
}

You can see that it return null. So when we mock the function, it will throw IllegalStateException, because argThat returns null and argument can't be null.

It mean that if your function is:

fun doSomething(arg1: String): Int {
    // do something
}

When you mock it like that:

Mockito.`when`(
    doSomething(Mockito.argThat<String> { true })
).thenReturn(100)

It will throw IllegalStateException

So you should change your function like that:

fun doSomething(arg1: String?): Int {
    // do something
}

Change the "String" to "String?", make it accept null type.

My solution is to define the argument with class? so that it can accept null, but I don't know if it is a great solution

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!

You don't need MockRestServiceServer object. The annotation is @InjectMocks not @Inject. Below is an example code that should work

@RunWith(MockitoJUnitRunner.class)
public class SomeServiceTest {
    @Mock
    private RestTemplate restTemplate;

    @InjectMocks
    private SomeService underTest;

    @Test
    public void testGetObjectAList() {
        ObjectA myobjectA = new ObjectA();
        //define the entity you want the exchange to return
        ResponseEntity<List<ObjectA>> myEntity = new ResponseEntity<List<ObjectA>>(HttpStatus.ACCEPTED);
        Mockito.when(restTemplate.exchange(
            Matchers.eq("/objects/get-objectA"),
            Matchers.eq(HttpMethod.POST),
            Matchers.<HttpEntity<List<ObjectA>>>any(),
            Matchers.<ParameterizedTypeReference<List<ObjectA>>>any())
        ).thenReturn(myEntity);

        List<ObjectA> res = underTest.getListofObjectsA();
        Assert.assertEquals(myobjectA, res.get(0));
    }

The lombok @Slf4j annotation injects code into your class at compile time. Specifically, it will add the following code to your class:

private static final org.slf4j.Logger log =
                        org.slf4j.LoggerFactory.getLogger(LogExample.class);

@InjectMocks is telling Mockito to create an instance of your class and inject mocks as its dependencies at runtime.

The logger is injected at compile time. Dependecies are injected at runtime. That's why your logger is not mocked and cannot be mocked like this. If you look at the injected logger code above, you will understand, that the only way to mock the logger is to mock the LoggerFactory (Mockito can mock static methods since version 3.4, IIRC) and make it return the logger mock.

NB: Making mocks return mocks is usually a bad idea and should be avoided. @Slf4j is too convenient to not be used. It's a tradeoff.

NB: If all you want it silencing the logger, then you could also just configure it to shut up in your tests.

To answer your second question first. If you're using JUnit 4, you can annotate your test with

@Test(expected=MyException.class)

to assert that an exception has occured. And to "mock" an exception with mockito, use

when(myMock.doSomething()).thenThrow(new MyException());

If you want to do a pure unit test then for the line

service.getJdbcTemplate().query("....");

You will need to mock the Service, then the service.getJdbcTemplate() method to return a mock JdbcTemplate object, then mock the query method of mocked JdbcTemplate to return the List you need. Something like this:

@Mock
Service service;

@Mock
JdbcTemplate jdbcTemplate;


@Test
public void testGetUserNames() {

    List<String> userNames = new ArrayList<String>();
    userNames.add("bob");

    when(service.getJdbcTemplate()).thenReturn(jdbcTemplate);
    when(jdbcTemplate.query(anyString(), anyObject()).thenReturn(userNames);

    String retVal = Class.getUserNames("test");
    assertEquals("bob", retVal);
}

The above doesn't require any sort of Spring support. If you were doing an Integration Test where you actually wanted to test that data was being pulled from a DB properly, then you would probably want to use the Spring Test Runner.