-
Notifications
You must be signed in to change notification settings - Fork 163
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
@GenerateMocks does not generate for void function without parameter #367
Comments
Nope; you are not doing anything wrong. |
I'm not sure I understand. I'm coming across a problem where I have methods similar to @EhiltonKazuo's which return void and have no parameters, and the generated mock class does not override them. Thus, when I call
By what you're saying, mockito should automatically handle these cases? My test file looks like this, btw:
|
So I got it to pass by modifying the annotation as suggested in the NULL_SAFETY_README: However, I don't know if this is what I should be doing since it is not the case that my method returns null. But I don't really know if a void return type is equivalent to returning null, so... |
I think you only use this, if your code is legacy. I will wait the new update to solve this. |
This is the behavior of mockito before the null safety migration. The From the standpoint of avoiding magic in your tests I'd personally recommend you avoid
@srawlins can correct me if I'm wrong, but I don't think we have any changes planned here. This is working as intended. If you are using |
@natebosch Thanks! So, by what I'm understanding, it would be best practice to actually return something for my methods, is that right? |
Actually, for #305, I did land changes to allow calling functions which return These shipped in 5.0.0-nullsafety.6. @mateusdeap can you show what version you are running? |
@mateusdeap I can reproduce this in a test, at HEAD; this bug slipped through the new tests that landed with that change. |
@srawlins Awesome then! I know you reproduced it at HEAD, but just for the information, I'm using 5.0.3 |
Having to stub a `void` function before calling it confuses developers. They write `when(mock.methodReturnsVoid(any)).thenReturn(` and then might really have to scratch their heads about what makes sense to return from a mock of a void function. And all this just to satisfy a requirement to have sane return values, which I think just doesn't apply to void (and `Future<void>` and `Future<void>?`) functions. This CL changes the logic that determines whether a method (or field, or setter) needs to be overridden. It now includes the case for these void-ish methods. Fixes #367 PiperOrigin-RevId: 367247168
@srawlins Is there an ETA for your fix? Experiencing the same thing as @mateusdeap... |
This fix has landed on HEAD. I'm waiting for internal review of one more change + a version bump, to be synced to GitHub. Likely tomorrow or Tuesday. |
Having to stub a `void` function before calling it confuses developers. They write `when(mock.methodReturnsVoid(any)).thenReturn(` and then might really have to scratch their heads about what makes sense to return from a mock of a void function. And all this just to satisfy a requirement to have sane return values, which I think just doesn't apply to void (and `Future<void>` and `Future<void>?`) functions. This CL changes the logic that determines whether a method (or field, or setter) needs to be overridden. It now includes the case for these void-ish methods. Fixes #367 PiperOrigin-RevId: 367247168
Having to stub a `void` function before calling it confuses developers. They write `when(mock.methodReturnsVoid(any)).thenReturn(` and then might really have to scratch their heads about what makes sense to return from a mock of a void function. And all this just to satisfy a requirement to have sane return values, which I think just doesn't apply to void (and `Future<void>` and `Future<void>?`) functions. This CL changes the logic that determines whether a method (or field, or setter) needs to be overridden. It now includes the case for these void-ish methods. Fixes #367 PiperOrigin-RevId: 367247168
Sorry but this still isnt fixed. My test fails because of this issue. |
@MilanObrenovic can you please provide:
Since this bug is so old, you are probably hitting a new, different issue, and you should open a new issue. |
version of mockito: ^5.0.16 (latest as of now) my test: test("Should perform database batch delete of chat.", () async {
// Arrange
const String chatId = "111";
when(mockDatabase.batch()).thenReturn(mockBatch);
// Act
await dataSourceImpl.deleteChat(
chatId: chatId,
);
// Assert
verifyInOrder([
mockDatabase.batch(),
mockBatch.delete(
"messages",
where: anyNamed("where"),
whereArgs: [chatId],
),
mockBatch.delete(
"chats",
where: anyNamed("where"),
whereArgs: [chatId],
),
mockBatch.commit(
noResult: true,
),
]);
}); deleteChat method: @override
Future<void> deleteChat({required String chatId}) async {
final Batch batch = _database.batch();
batch.delete(
"messages",
where: "chat_id = ?",
whereArgs: [chatId],
);
batch.delete(
"chats",
where: "id = ?",
whereArgs: [chatId],
);
await batch.commit( // <--- THE CRASH HAPPENS BECAUSE OF THIS LINE !!!
noResult: true,
);
} error:
The error message looks pretty straightforward. I tried adding those optional nullable parameters "exclusive" and "continueOnError" to be non-nullable, but got the same error. I also i tried replacing the batch with nullable on stub generation: @GenerateMocks([Database], customMocks: [MockSpec<Batch>(returnNullOnMissingStub: true)]) But this prints a different error message:
No idea how to fix this for over several weeks. Let me know if i should create a new issue. |
@MilanObrenovic This is unrelated to #367.
When you don't provide a stub, and use |
so how do i fix this crash? |
Did you try the other suggestion from the error?
|
but i thought i already added that with this piece of code? when(mockDatabase.batch()).thenReturn(mockBatch); |
No that is stubbing the You need to stub the |
now it worked... when(mockBatch.commit(
noResult: true,
)).thenAnswer((_) async => []); solved the issue. thank you very much. |
Having to stub a `void` function before calling it confuses developers. They write `when(mock.methodReturnsVoid(any)).thenReturn(` and then might really have to scratch their heads about what makes sense to return from a mock of a void function. And all this just to satisfy a requirement to have sane return values, which I think just doesn't apply to void (and `Future<void>` and `Future<void>?`) functions. This CL changes the logic that determines whether a method (or field, or setter) needs to be overridden. It now includes the case for these void-ish methods. Fixes dart-lang/mockito#367 PiperOrigin-RevId: 367247168
I'm new in mockito and null safety operators, but i followed the NULL_SAFETY_README. This is the annotation that im using:
@GenerateMocks([], customMocks: [MockSpec<LoginPresenter>(as: #LoginPresenterSpy)])
This is the sample of LoginPresenter:
And this is the generate code build_runner:
But doesn't exist the auth and dispose functions. Am i doing wrong?
The text was updated successfully, but these errors were encountered: