mocking a method that return generics with wildcard using mockito
Solution 1
EDIT : Starting from Mockito 1.10.x, generics types that are embedded in the class are now used by Mockito for deep stubs. ie.
public interface A<T extends Observer & Comparable<? super T>> {
List<? extends B> bList();
T observer();
}
B b = deep_stubbed.bList().iterator().next(); // returns a mock of B ; mockito remebers that A returns a List of B
Observer o = deep_stubbed.observer(); // mockito can find that T super type is Observer
Comparable<? super T> c = deep_stubbed.observer(); // or that T implements Comparable
Mockito tries its best to get type information that the compiler embeds, but when erasure applies, mockito cannot do anything but return a mock of Object
.
Original : Well that's more of an issue with generics than with Mockito. For generics, you should read what Angelika Langer wrote on them. And for the current topic, i.e. wildcards, read this section.
But for short, what you could use is the other syntax of Mockito to help with your current situation :
doReturn(interfaces).when(classAMock).getMyInterfaces();
Or with the BDD aliases :
willReturn(interfaces).given(classAMock).getMyInterfaces();
Nevertheless, you could write wrappers that are more generic friendly. That will help future developers working with same 3rd party API.
As a side note: you shouldn't mocks type you don't own, it can lead to many errors and issues. Instead you should have some wrapper. DAO and repositories for example represent such idea, one will mock the DAO or repository interface, but not the JDBC / JPA / hibernate stuff. There are many blog posts about that:
- http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html
- http://blog.8thlight.com/eric-smith/2011/10/27/thats-not-yours.html
- https://web.archive.org/web/20140923101818/http://freshbrewedcode.com/derekgreer/2012/04/01/tdd-best-practices-dont-mock-others/
- ...
Solution 2
Another solution (albeit less readable) is to qualify the static method call of when
to bind the wildcard:
Mockito.<List<? extends MyInterface>>when(classAMock.getMyInterfaces()).thenReturn(interfaces);
user1504992
Updated on October 03, 2020Comments
-
user1504992 over 3 years
I'm using mockito 1.9.5. I have the following code:
public class ClassA { public List<? extends MyInterface> getMyInterfaces() { return null; } public static void testMock() { List<MyInterface> interfaces = new ArrayList<>(); ClassA classAMock = mock(ClassA.class); when(classAMock.getMyInterfaces()).thenReturn(interfaces); }
I get a compilation error for the
thenReturn(interfaces)
saying:"The method thenReturn(List<capture#1-of ? extends MyInterface>) in the type OngoingStubbing<List<capture#1-of ? extends MyInterface>> is not applicable for the arguments (List<MyInterface>)"
However, when I use the
thenAnswer
method of mockito, I don't get the error. Can anyone tell me what's going on? Why do I get the error when I use thethenReturn
method? Is there any other way to solve this problem whenClassA
is provided by a 3rd party and cannot be modified? -
ChenZhou over 10 yearsThanks also for the insightful links!
-
Paŭlo Ebermann over 9 yearsThe
doReturn
syntax is not type-safe, though (you could return anything, not just a list of something). (Though you then get an exception still during this setup – but not if you put in a different kind of list.) -
Brice over 9 years@PaŭloEbermann Indeed, this is due to type erasure. In this case the check is done at runtime. The other form can be type checked at compile time.
-
Big_Bad_E almost 4 yearsProbably because type erasure prevents Mockito from getting more info from the generic, so it doesn't know if the generic is a <?> or a <? extends MyInterface>, by adding the generic's type in front of the method, you prevent the guesswork caused by type erasure.