How to use cannotMockClass method of org.mockito.internal.exceptions.Reporter class

It sounds like you may want to be using the .expects(1) type methods that mock frameworks usually provide.

Using mockito, if you were testing a List and wanted to verify that clear was called 3 times and add was called at least once with these parameters you do the following:

List mock = mock(List.class);        
someCodeThatInteractsWithMock();                 

verify(mock, times(3)).clear();
verify(mock, atLeastOnce()).add(anyObject());      

Source - MockitoVsEasyMock

Yes, you are on the right track, putting a mock @Bean in a @Configuration class is one approach, and I'll describe my experience:

The trick is that you need to use a different set of .xml files purely for testing which exclude the live versions of those beans.

@ContextConfiguration(locations = {"context1-test.xml", "context2-test.xml", ...})

And the "-test-xml" files go in src/test/resources.

At least that was my experience in doing the same thing. Maybe there is some way to "override" the beans with the mock versions, but as yet I am not aware of it.

I also chose to put the mocks (I had 5 of them) all together in an own configuration:

@Configuration
public class MockServicesProvider {
     @Bean
     public AnotherBean myMock() { return mock(AnotherBean.class); }
}

Another interesting part of this problem is the common usage of initMocks(this); in the @Before method of your test class.

If the mocks are being used in other places (and they are, that's why you are wiring them up...) then initMocks(this) will blow them away between tests (not literally - just that new mocks will be created and any other mocks wired up in other objects will be "lost").

The solution to this was to call mockito's reset(mockObject) in the @Before method before each test. The same mocks are reset (all the when's and interactions), without creating new mocks.

Note that the Mockito docs for reset say very sternly that this method should not commonly be used, except in the context of mocks being applied via dependency injection, as we are indeed doing in this case :)

Have fun!

As mentioned on the mockito github:

It looks like this has to do with calling when the second time. I couldn't find what was going on, but the second when doesn't attempt to add the mock logic, it just calls the method. Replacing with doReturn().when() works.

    doReturn(expected1).when(overloadedMethods).getString(any());
    doReturn(expected2).when(overloadedMethods).getString(any(), any());

https://github.com/mockito/mockito/issues/1496#issuecomment-423310950 DavidTanner

You can use a Mockito Spy for this. If you setup anotherObj as a spy you can verify method calls on that object. In your example you need to make sure that the call to foo uses the spy instead of an ordinary implementation of anotherObj. The spy is setup something like this:

AnotherClass anotherObjSpy = Mockito.spy(new AnotherClass());
// do stuff -- e.g. anotherObjSpy.foo(...);
verify(anotherObjSpy).codePath1(...);

Do not cast Matchers.anyVararg(), there is better solution.

Method queryForList has signature

queryForList(String sql, SqlParameterSource paramSource, Class<T> elementType)

so instead of

when(jdbt.queryForList(Matchers.anyString(), 
                       Matchers.any(MapSqlParameterSource.class),
                       Matchers.any(Integer.class))).thenReturn(idList); 

use

when(jdbt.queryForList(Matchers.anyString(), 
                       Matchers.any(MapSqlParameterSource.class), 
                       Matchers.<Class<Integer>>any())).thenReturn(idList);

as described in Mockito: Verifying with generic parameters

Do not use code with anyVararg() and casting

when(jdbt.queryForList(Matchers.anyString(), 
                       Matchers.any(MapSqlParameterSource.class), 
                       (Class<Object>) Matchers.anyVararg()).thenReturn(idList);

because this generate warning

Unchecked cast: `java.lang.Object` to `java.lang.Class<java.lang.Object>`

According tho the Mockito documentation for Spy,

Spying on real objects is often associated with "partial mocking" concept. However, Mockito spies are not partial mocks. Mockito spy is meant to help testing other classes - not the spy itself. Therefore spy will not help if you intend to verify if method calls other method on the same object. In this case I suggest being OO/SRPy (for example you might extract new class/interface...)

The OO refers to object-oriented, and SRP refers to Single responsibility principle. It is a design pattern that states the class should have one and only one responsibility, and in this case it you would tend to write code that doesn't need to test if internal methods are called.

http://en.wikipedia.org/wiki/Single_responsibility_principle

It seems that this might be caused because it can't find bytebuddy installed, referring to:

Caused by: java.lang.NoSuchMethodError: net.bytebuddy.dynamic.loading.MultipleParentClassLoader$Builder.appendMostSpecific(Ljava/util/Collection;)Lnet/bytebuddy/dynamic/loading/MultipleParentClassLoader$Builder;

From what I can find online adding bytebuddy to your dependencies might fix this.

    <dependency>
      <groupId>net.bytebuddy</groupId>
      <artifactId>byte-buddy</artifactId>
      <version>XXX</version>
    </dependency>

This should work

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

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

You can also use the non-type safe method doReturn for this purpose,

@Test
public void testMockitoWithGenerics()
{
    DummyClass dummyClass = Mockito.mock(DummyClass.class);
    List<? extends Number> someList = new ArrayList<Integer>();

    Mockito.doReturn(someList).when(dummyClass).dummyMethod();

    Assert.assertEquals(someList, dummyClass.dummyMethod());
}

as discussed on Mockito's google group.

While this is simpler than thenAnswer, again note that it is not type safe. If you're concerned about type safety, millhouse's answer is correct.

Additional Details

To be clear, here's the observed compiler error,

The method thenReturn(List<capture#1-of ? extends Number>) in the type OngoingStubbing<List<capture#1-of ? extends Number>> is not applicable for the arguments (List<capture#2-of ? extends Number>)

I believe the compiler has assigned the first wildcard type during the when call and then cannot confirm that the second wildcard type in the thenReturn call is the same.

It looks like thenAnswer doesn't run into this issue because it accepts a wildcard type while thenReturn takes a non-wildcard type, which must be captured. From Mockito's OngoingStubbing,

OngoingStubbing<T> thenAnswer(Answer<?> answer);
OngoingStubbing<T> thenReturn(T value);