@GenerateMocks does not work on Generic method return types

[MaxAuer]

Hey,

I tried to create a Mock for the following Function:

T add<T extends Base>(T data);

Several Classes are extending Base.

flutter pub run build_runner build throws the following error The method 'Api.add' features a non-nullable unknown return type, and cannot be stubbed.

I am using Mockito: ^5.0.0-nullsafety.7

Any way to get around this?

[srawlins]

Good question. It will be tricky, and I think we'll need to add new functionality. There are really two problems here. Looking at an example class:

class C {
  int get m => 0;
  String s(String a) => a;
  /// 100 other methods you'd like to stub...
  T add<T>(T data) => data;
}

1. The broad, more common problem is that mockito right now will refuse to generate a stub for this entire class, because "The method 'C.add' features a non-nullable unknown return type, and cannot be stubbed." There is no mechanism to write code that instantiates T values at compile time. (Even for this case where you are offered a free parameter of type T, mockito always expands parameter types to be nullable (T?), so the parameter is not usable as a dummy return value. A user might say, "I don't care about add, I just need to stub the other 100 methods." I think this issue is fairly high priority.
2. The more acute, and less common problem is that a user says, "I'd like to stub add. How do I do it?"
   CC @TedSander @matanlurey @natebosch for input.

We can solve the problems separately. There are a few ways to solve the first:

1. Instead of throwing this error at compile-time, implement an add function which just throws at runtime. This could be implemented as opt-in or opt-out behavior when declaring a custom mock.

2. We could allow users to declare a mixin of their own devising which is mixed into the generated class. Something like:

   mixin MockCAddMixin on C {
     T add<T>(T data) => data; // dummy function satisfying implementation
   }

   and the generated code looks something like:

   class MockC extends Mock implements C with MockCAddMixin {
     // No implementations of any methods found in MockCAddMixin.
     // ...
   }

3. For any methods like add, we always add an optional named or positional parameter, something like T dummyReturnValue, which must be supplied (but must be positional for type system reasons). This is very distasteful for a few reasons. If add has optional positional parameters, it would have to be positional, and come last, and so users would always have to pass arguments for every parameter. Yuck. If add has optional named parameters, then the new parameter would have to be named, which is now a weird inconsistency. This also exposes ugly internals of mockito, requiring users to create a T, and pass it, and it is not at all part of the stubbing, it's just a necessary evil object.

I haven't really thought of solutions for the second problem. Maybe user-authored mixin would work here too, if it can somehow call Mock.noSuchMethod...

[MaxAuer]

Thanks for the detailed response @srawlins.

I agree that problem 1. is the more common and probably the issue that will surface a lot when null safety becomes the new default.

Solution 2. of using a Mixin to fall back to sounds good enough to handle such cases. I also agree that 3. does not seem to be user-friendly.

The second problem is definitely the one I am stuck on right now. But more so in combination with Futures #339. I think those two problems are pretty similar.

[srawlins]

Regarding the second problem, I think you can even get real mock support. Here is a rough mockup showing how you can use super.noSuchMethod to route back into mockito's stubbing and verification mechanics:

class Mock {
  noSuchMethod(Invocation i) {
    print(i.positionalArguments);
    print('mock.nsm');
    return 6;
  }
}

class C {
  T f<T>(T obj) => obj;
}

mixin Mixin on Mock, C {
  T f<T>(T obj) {
    if (obj is int) {
      return super.noSuchMethod(Invocation.genericMethod(#f, [int], [1]));
    } else if (obj is double) {
      return super.noSuchMethod(Invocation.genericMethod(#f, [double], [1.5]));
    }
    throw 'boo';
  }
}

abstract class _MockC extends Mock implements C {}

class MockC extends _MockC with Mixin {}

void main() {
  MockC c = MockC();
  c.f(7);
  c.f(7.5);
}

[natebosch]

Would it be feasible to allow defining a top-level method with a matching generic signature, and configure the mock to defer to that implementation when there is no stub?

[srawlins]

@natebosch very cool idea. I'm going to prototype this. I haven't been very happy with my mixin idea because of the generics issues.

[eggnstone]

Do you have a workaround for problem 1?
I looked at #342 but it's not clear to me if this is a working solution. E.g. "mixingIn" is not a param for MockSpec.

[srawlins]

Right its not a solution yet. I prototyped the top-level method idea this weekend and hope to loop back with my results today.

[eggnstone]

Any news or ETA please?

[srawlins]

This will likely land within the next 40 days.

[srawlins]

This is available now with Mockito 5.0.9. Please see the new section in the NULL_SAFETY_README:

https://github.com/dart-lang/mockito/blob/master/NULL_SAFETY_README.md#fallback-generators

[ngxingyu]

Works well for me! thanks