Add Support For Generics Inference In Mockito mock() and spy() method

[ankurpathak]

EasyMock with its version 4 added support for Generics to get rid of Annoying Unchecked Warning while
mocking types with Generics Involved. So we expect the same with Mockito, in its mock() and spy() to add
support for generics type inference, so that the developers have not to deal with annoying Uncheked
warning in Test and annotate tests with SuppressWarnings({"unchecked"}). For a motivation for same we
can have a look at emptyList(), empthMap() and emptySet() method of Collections class in JDK.
And also have a look at the way it is done in EasyMock 4.0 in this class:
https://github.com/easymock/easymock/blob/master/core/src/main/java/org/easymock/EasyMock.java

[brachi-wernick]

@ankurpathak if you will check what EasyMock did, they make the createMock function not strongly typed.
means, you really can do

  BaseGenericClass<Integer> mock = EasyMock.createMock(BaseGenericClass.class);

but you can also do

    BaseGenericClass<Integer> mock = EasyMock.createMock(Set.class);

very strange, ha?!

I'll try to give a better fix...

[SerialVelocity]

@brachi-wernick This is already done for ArgumentCaptor:

mockito/src/main/java/org/mockito/ArgumentCaptor.java

Lines 148 to 150 in 41c5606

	public static <U,S extends U> ArgumentCaptor<U> forClass(Class<S> clazz) {
	return new ArgumentCaptor<U>(clazz);
	}

It doesn't make it completely typed as you can accidentally give it Object or some inherited class but it is a nice compromise :)

[bric3]

Hi,

While it is not exactly what you are looking for, please note that at this time, if the types to mock are declared as fields in a test, then the compiler will propagate types.

import org.junit.Rule;
import org.junit.Test;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnit;
import org.mockito.junit.MockitoRule;

import java.util.Map;

import static java.lang.Long.MAX_VALUE;
import static java.util.Collections.singleton;
import static org.assertj.core.api.Assertions.assertThat;
import static org.mockito.BDDMockito.given;

public class GenericFieldTest {

    @Rule
    public MockitoRule rule = MockitoJUnit.rule();

    @Mock
    private Map<Number, Iterable<String>> typeToMock;

    @Test
    public void should_propagate_generics() {
        given(typeToMock.get(MAX_VALUE)).willReturn(singleton("max"));
        given(typeToMock.put(MAX_VALUE, singleton("max"))).willReturn(singleton("maximum"));

        assertThat(typeToMock.put(MAX_VALUE, singleton("max"))).isEqualTo(singleton("maximum"));
        assertThat(typeToMock.get(MAX_VALUE)).isEqualTo(singleton("max"));
    }
}

Also we discussed about the trick that easy mock used, and we're not really sold to it because of the drawbacks mentioned above. Some other libraries employs other approaches that are safer but require a stronger commitment to the codebase.

[thandy1212]

@SerialVelocity why does ArgumentCaptor have two type parameters? That allows something like the following doesn't it:

ArgumentCaptor<Object> ac = ArgumentCaptor.forClass(Integer.class);

which isn't semantically accurate. That's saying you're trying to declare an ArgumentCaptor that can take anything from an ArgumentCaptor that can only take Integers

If you try something similar with Lists it wouldn't compile:

// Won't compile
List<Object> ol = new ArrayList<Integer>();

[SerialVelocity]

@thandy1212 I'm just stating what already exists in Mockito, not something new.

I assume it was done because you don't really care about what subclass it is implementing. If you pass ac.capture() into something that accepts an object, so be it. All you've done is limited the type you get out when checking what value was passed in. e.g. In the current world, you can do:

void bob(Object o) {}

ArgumentCaptor<Integer> ac = ArgumentCaptor.forClass(Integer.class);
bob(ac.capture());

It's the same as if you had:

void bob(Object o) {}

ArgumentCaptor<Object> ac = ArgumentCaptor.forClass(Integer.class);
bob(ac.capture());

The only thing you have restricted is you cannot call void bob(Integer i) {} anymore.

[mjustin]

As of this writing, there are 292 upvotes for the related Stack Overflow question around mocking with generic parameters. This indicates to me that there is definitely an interest in having a clean solution to this problem.

[TimvdLippe]

Given that .class does not play well with generics, I don't think there is any solution we can do in Mockito. You can already do @Mock (the JUnit5 extension also allows method parameter @Mocks) and that should be a suitable alternative. Therefore, we can keep this issue open, but it is unlikely ever to be fixed, given that @Mock is a better API.

[mjustin]

A problem I've seen with @Mock is when there's code which dynamically creates a mock, or wants it to be method scoped. In this case, a field can be problematic.

[TimvdLippe]

Since you are dynamically creating the mock, it means you are creating it on runtime. Because of type erasure, at runtime these generics types are not checked. Therefore, I don't think it is possible to create a type-safe API with .class.

[mjustin]

@TimvdLippe Agreed, regarding using Class. What I've seen other libraries do is use a parameterized type reference class for this purpose (based on an approach by Neal Gafter).

Examples:

• Jackson: TypeReference, JavaType
• Spring Core: ParameterizedTypeReference
• Guava: TypeToken

The code could then look something like:

List<String> mock = mock(new TypeReference<List<String>>(){});

[JoshMcCullough]

I don't like ignoring warnings and I hate adding warning-ignore comments in code (they don't belong there). Please help!

[jlerbsc]

Hi, Have you planned to resolve this issue?