Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditionally disable fakes #409

Closed
cadaniel opened this issue May 14, 2021 · 8 comments
Closed

Conditionally disable fakes #409

cadaniel opened this issue May 14, 2021 · 8 comments
Assignees
Labels
type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@cadaniel
Copy link

I'm using the generator, and I'm having troubles with the generated fake classes from moor.

Object.==' ('bool Function(Object)') isn't a valid concrete implementation of 'User.==' ('bool Function(dynamic)').

I've opened an issue with moor at simolus3/drift#1192 but in the mean time, I would like to conidtionally disable Fakes. I don't use them when stubbing personally, instead feeding 'real' classes.

@srawlins
Copy link
Member

Thanks for opening an issue.

The code you point to is probably in a generated mock, not a generated fake.

@cadaniel
Copy link
Author

cadaniel commented May 14, 2021

@srawlins

The offending line of code is

class _FakeUser extends _i1.Fake implements _i3.User {}

It is inside of a generated mock yes.

@srawlins
Copy link
Member

Ah that is very interesting. Even this tiny snippet results in the error you show:

class User {
  bool operator == (dynamic other) => true;
}

class FakeUser extends Fake implements User {}

class Fake {
  dynamic noSuchMethod(_) {}
}

I really think the Moor classes should not override operator == to accept a dynamic parameter...

In any case, this class is required in order to generate your mocks. If you search the generated library for references to _FakeUser, you will see where it is needed.

@cadaniel
Copy link
Author

I'm sssoooo close to being able to use the generator again. I don't use the Fakes anyways, is there a way to turn them off for now?

@srawlins
Copy link
Member

No. If a fake is referenced in the generated library, then it is necessary. Otherwise the code would reference a type which doesn't exist.

@cadaniel
Copy link
Author

cadaniel commented May 14, 2021

That's not 100% true.

EDIT: Give me a moment and I'll find a better one that isn't a stream.

So here's a function that fetches an object for me from the repository.

Future<ExerciseEvent?> getLastEvent() => exerciseRepository.getLastEvent();

Here's what the generator returns

 @override
  _i12.Future<_i3.ExerciseEvent?> getLastEvent() => (super.noSuchMethod(
          Invocation.method(#getLastEvent, []),
          returnValue: Future<_i3.ExerciseEvent?>.value(_FakeExerciseEvent()))
      as _i12.Future<_i3.ExerciseEvent?>);

Where here's what I edited from the generator to make work without using the fake.

  @override
  _i11.Future<ExerciseEvent?> getLastEvent() =>
      (super.noSuchMethod(Invocation.method(#getLastEvent, []),
              returnValue: Future<ExerciseEvent?>.value(null))
          as _i11.Future<ExerciseEvent?>);

So because it's null, I can just return null.

But even if ti wasn't nullable, You could still throw a notImplemented exception instead of a fake no?

@cadaniel
Copy link
Author

I'll let you decide if further action is needed. Moor has just fixed this making it kinda moot for now

@srawlins srawlins reopened this May 14, 2021
@srawlins
Copy link
Member

Your example is intriguing; this easily looks like a bug/shortcoming that we can address in mockito; I'll re-open to fix this.

Thanks for digging it up!!!

@srawlins srawlins self-assigned this May 17, 2021
@srawlins srawlins added the type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) label May 17, 2021
srawlins added a commit that referenced this issue May 17, 2021
…ype in a Future.

Fixes #409

Other containers do not feature this problem, like List, Stream, etc, as they are allowed to be empty. A Future can only be empty in this nullable type case.

PiperOrigin-RevId: 374242451
srawlins added a commit that referenced this issue May 17, 2021
…ype in a Future.

Fixes #409

Other containers do not feature this problem, like List, Stream, etc, as they are allowed to be empty. A Future can only be empty in this nullable type case.

PiperOrigin-RevId: 374242451
srawlins added a commit that referenced this issue May 18, 2021
…ype in a Future.

Fixes #409

Other containers do not feature this problem, like List, Stream, etc, as they are allowed to be empty. A Future can only be empty in this nullable type case.

PiperOrigin-RevId: 374242451
srawlins added a commit that referenced this issue May 18, 2021
…ype in a Future.

Fixes #409

Other containers do not feature this problem, like List, Stream, etc, as they are allowed to be empty. A Future can only be empty in this nullable type case.

PiperOrigin-RevId: 374242451
srawlins added a commit that referenced this issue May 18, 2021
…ype in a Future.

Fixes #409

Other containers do not feature this problem, like List, Stream, etc, as they are allowed to be empty. A Future can only be empty in this nullable type case.

PiperOrigin-RevId: 374242451
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

2 participants