-
Notifications
You must be signed in to change notification settings - Fork 160
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
Comments
Thanks for opening an issue. The code you point to is probably in a generated mock, not a generated fake. |
The offending line of code is
It is inside of a generated mock yes. |
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 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. |
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? |
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. |
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.
Here's what the generator returns
Where here's what I edited from the generator to make work without using the fake.
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? |
I'll let you decide if further action is needed. Moor has just fixed this making it kinda moot for now |
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!!! |
…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
…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
…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
…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
…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
I'm using the generator, and I'm having troubles with the generated fake classes from moor.
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.
The text was updated successfully, but these errors were encountered: