There is no way to generate a mock of Foo<Bar> if Bar is a type parameter bound

[yanok]

Assume we have

@GenerateMocks([], customMocks: [MockSpec<Foo<Bar>>(as: #FooBar)])
import 'test.mocks.dart';

class Bar {}
abstract class Foo<T extends Bar> {
  T m();
}

This is supposed to work without unsupportedMembers since T gets instantiated to the concrete type Bar, but the codegen can't actually take apart Foo<Bar> from just Foo (analyzer limitation?), so it assumes it's Foo and generates a mock for the generic type, even though an instantiated version was requested, requiring to add unsupportedMembers or fallbackGenerators.

[srawlins]

Yeah I think we can't tell in the element model if T was instantiated to its bound, or if it's bound was provided directly.

[srawlins]

One way to support this would be to add a flag which sends an explicit signal to mockito code-gen to "make this non-generic." Something like MockSpec(instantiateToBound: true).

[yanok]

One way to support this would be to add a flag which sends an explicit signal to mockito code-gen to "make this non-generic." Something like MockSpec(instantiateToBound: true).

Yeah, that would be a possible workaround but it really feels wrong that user has to tell us this explicitly. Why would I (as an user) even care I instantiate it with the exact bound?

I would argue that since Foo actually means Foo<Bar> in Dart (I don't approve that BTW ;)), it should be the other way around: the default is to generate a mock for Foo<Bar> and have an explicit flag to generate a generic one... But that would mean breaking the existing usage...

I found another workaround BTW: we can do ElementAnnotation.toSource() and check whether Foo was passed with type arguments or not... But that is super freaking hacky...

[srawlins]

Yeah, that would be a possible workaround but it really feels wrong that user has to tell us this explicitly.

Agreed.

I found another workaround BTW: we can do ElementAnnotation.toSource() and check whether Foo was passed with type arguments or not... But that is super freaking hacky...

Yeah, agreed. ☹️

[scheglov]

I don't understand why you need to distinguish. Both Foo and Foo<Bar> produce the same type.
I probably don't know enough of Mockito to understand the description in the initial comment.

[srawlins]

When a user wants to say, "I want to generate a mock class for Foo", our API lets them do that with an annotation:

MockSpec<Foo>

However, with an annotation like that, there is no way to specify whether they want a generic mock (class MockFoo<T> extends Mock implements Foo<T>) or a mock extending Foo with its type parameters instantiated-to-bounds (class MockFoo extends Mock implements Foo<dynamic>).

(Long story) We currently assume they want a generic one, because who wants dynamic yuck. But in the case of a non-dynamic bound, like Bar, it seems more common to want a non-generic mock which implements Foo<Bar>. That generic-vs-nongeneric distinction becomes important for complicated reasons around methods which return the type variable (a method like T getSomething()). It is impossible for mockito to override this method in the generic case, but it can override the instantiated case.

[scheglov]

Can you add a parameter to MockSpec constructor that explicitly says whether a generic mock should be generated? Just like as.

[srawlins]

That is my idea above 😄

[scheglov]

Yes, almost. I just thought (randomly) to ask explicitly for generic. Now, I can rationalize it by saying that Foo means Foo<Bar>, so by default you ask for instantiated version.

It seems that what we need it a reference to a class, and pass it to MockSpec.generic(#Foo) (if #Foo actually meant the reference).

[yanok]

Yes, I agree that it makes more sense to get the instantiated class by default and only make it generic if asked explicitly (with almost the same argument, see my comment), but that's a breaking API change. Well, maybe we can break the new @GenerateNiceMocks API, which it not used much yet...