Mockito: Stubbing Methods That Return Type With Bounded Wild-Cards

Question

Consider this code:

public class DummyClass {
    public List<? extends Number> dummyMethod() {
        return new ArrayList<Integer>();
    }
}

public class DummyClassTest {
    public void testMockitoWithGenerics() {
        DummyClass dummyClass = Mockito.mock(DummyClass.class);
        List<? extends Number> someList = new ArrayList<Integer>();
        Mockito.when(dummyClass.dummyMethod()).thenReturn(someList); //Compiler complains about this
    }
}

The compiler complains about the line that's trying to stub the behavior for dummyMethod(). Any pointers on how one goes about stubbing methods that return a type with bounded wild-cards?

Triboelectricity

Can you update your code snippet to show the generic types? – Cervine

Done. I had to remove pre and code tags, they were stripping-off <? extends Number> from the type declaration. – Triboelectricity

Answer 1

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

Hellenize

this partially help me as well... but what happens if the list you expect to return is not empty? – Continent

instead of having an empty list you can you can also do : List<Number> someList = new ArrayList<Integer>(); someList.add(aNumber); – Continent

This answer around the same question is quite nice : https://mcmap.net/q/145543/-mocking-a-method-that-return-generics-with-wildcard-using-mockito – Grundy

Answer 2

I'm assuming you want to be able to load up someList with some known values; here's an approach that uses Answer<T> together with a templated helper method to keep everything type-safe:

@Test
public void testMockitoWithGenericsUsingAnswer()
{
    DummyClass dummyClass =  Mockito.mock(DummyClass.class);

    Answer<List<Integer>> answer = setupDummyListAnswer(77, 88, 99);
    Mockito.when(dummyClass.dummyMethod()).thenAnswer(answer);

    ...
}

private <N extends Number> Answer<List<N>> setupDummyListAnswer(N... values) {
    final List<N> someList = new ArrayList<N>();

    someList.addAll(Arrays.asList(values));

    Answer<List<N>> answer = new Answer<List<N>>() {
        public List<N> answer(InvocationOnMock invocation) throws Throwable {
            return someList;
        }   
    };
    return answer;
}

Cervine

Answer 3

I hit the same thing yesterday. Both answers from @nondescript1 and @millhouse helped me to figure out a workaround. I've pretty much used the same code as @millhouse, except that I made it slightly more generic, because my error wasn't caused by a java.util.List, but the com.google.common.base.Optional. My little helper method therefore allows for any type T and not just List<T>:

public static <T> Answer<T> createAnswer(final T value) {
    Answer<T> dummy = new Answer<T>() {
        @Override
        public T answer(InvocationOnMock invocation) throws Throwable {
            return value;
        }
    };
    return dummy;
}

With this helper method you could write:

Mockito.when(dummyClass.dummyMethod()).thenAnswer(createAnswer(someList));

This compiles just fine and does the same thing as the thenReturn(...) method.

Does someone know if the error that the Java compiler emits is a compiler bug or if the code is really incorrect?

Andris

This seems straightforward, simple and, as near as I can tell, correct. I'm not sure why Mockito does not provide something similar to this.......unless it does? – Borst

In Java 8 it can be shortened: Mockito.when(dummyClass.dummyMethod()).thenAnswer(x -> someList), so no need for the utility method – Dorina

@Dorina What a great discovery "thenAnswer" ! – Geometrid

You can write it quite elegantly like this: public static <T> Answer<T> createAnswer(final T value) { return (invocation) -> value; } – Louisiana

Answer 4

I'm turning fikovnik's comment into an answer here to give it more visibility as I think it's the most elegant solution using Java 8+.

The Mockito documentation recommends using doReturn() (as suggested in the accepted answer) only as a last resort.

Instead, to circumevent the compiler error described in the question, the recommended Mockito when() approach can be used with thenAnswer() and a lambda (instead of a helper method):

Mockito.when(mockedClass.mockedMethod()).thenAnswer(x -> resultList)

Snowshed

though it doesn't give any compile time errors, the returned list is empty even when we are passing a list with entries. – Cervantes

Answer 5

Although the utility method proposed by Marek Radonsky works, there is also an other option which doesn't even require the (IMHO strange looking) lambda expression fikovnik suggested:

As this answer to a similar question shows, you can also use the following:

BDDMockito.willReturn(someList).given(dummyClass).dummyMethod();

Verger

Answer 6

Remove ? extends from your DummyClass return type.

Noncompliant Code Example:

--List<? extends Number> dummyMethod() {...}--

Compliant Solution

List<Number> dummyMethod() {
  
  List<Integer> result = ...
  return List.copyOf(result);
}

NOTE: List.copyOf() implementation is performant if your collection is created with List.of, Stream.toList, etc., effectively doing a cast rather than a real copy. See its source code: src 1, src 2.

JUSTIFICATION: Using a wildcard like <? extends Number> in the return type is a critical "Code Smell". Because would force your client code to struggle with wildcard-type declarations, as in your example with Mockito.

REFERENCEs:

• Joshua Bloch "Effective Java" Item 31:

Do not use <> wildcard types as return types, because it would force client code to use wildcards. Properly used, wildcards are nearly invisible to the user of a class. If the user of a class has to think about wildcard types, there is probably something wrong with its API.

• Sonar code quality Rule java:S1452
  • category: Code smell; severity: Critical

It is highly recommended not to use wildcard types as return types. Because the type inference rules are fairly complex it is unlikely the user of that API will know how to use it correctly.

...covariance is ineffective for the return type of a method since it is not an input position. Making it contravariant also has no effect since it is the receiver of the return value which must be contravariant (use-site variance in Java). Consequently, a return type containing wildcards is generally a mistake.

Cantonese