Mockito: Stubbing Methods That Return Type With Bounded Wild-Cards
Solution 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);
Solution 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;
}
Solution 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?
Solution 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)
Related videos on Youtube
Shikhar Mishra
Shikhar Mishra Enjoys all things software engineering https://www.explainxkcd.com/wiki/index.php/1691:_Optimization
Updated on July 08, 2022Comments
-
Shikhar Mishra almost 2 years
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?-
millhouse over 12 yearsCan you update your code snippet to show the generic types?
-
Shikhar Mishra over 12 yearsDone. I had to remove pre and code tags, they were stripping-off <? extends Number> from the type declaration.
-
-
vacao over 8 yearsThis 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?
-
fikovnik over 8 yearsIn Java 8 it can be shortened:
Mockito.when(dummyClass.dummyMethod()).thenAnswer(x -> someList)
, so no need for the utility method -
borjab about 8 years@fikovnik What a great discovery "thenAnswer" !
-
ttati over 7 yearsthis partially help me as well... but what happens if the list you expect to return is not empty?
-
ttati over 7 yearsinstead of having an empty list you can you can also do : List<Number> someList = new ArrayList<Integer>(); someList.add(aNumber);
-
Venkatesh Kolla - user2742897 over 4 yearsthough it doesn't give any compile time errors, the returned list is empty even when we are passing a list with entries.
-
potame almost 3 yearsThis answer around the same question is quite nice : stackoverflow.com/a/19119230/4214921