Change async stubbing to use thenAnswer. #13521
Conversation
Mockito now prohibits calling thenReturn with Futures and Streams. dart-lang/mockito#79
|
We have to do a pub release for mockito. It's going to be a 3.0 alpha release. I'll update the pull request with that shortly. |
|
Please make sure you did the pubspec.yaml fixes by running |
|
Hey @Hixie. Ted did a new release of Mockito. It's an alpha release. When I run that command, it updates it to the latest stable release, not alpha release. Is there anything I can do to update the deps to the alpha release? I just don't want anyone to cause an accidental breakage in the future. |
|
It probably means some other package we depend on depends on a range that doesn't include the new version. |
This reverts commit e8ab9d3. I did not correctly update the mockito dep, and there's no easy way to update to 3.0 alpha right now.
|
Ok, I'll just revert the dep change then. Thanks. |
|
Rather than Other than that, LGTM. |
|
Done. Thank you. |
|
The lint checks seem to require specifying a type for function expressions. I'm not sure why since this is against Effective Dart (https://www.dartlang.org/guides/language/effective-dart/design#avoid-annotating-types-on-function-expressions). I guess the Flutter style guide is different? @Hixie How strongly do you feel about " |
|
Flutter's codebase is intended to be fully typed, so that we don't rely on inference or dynamic. It has frequently helped us catch bugs. I prefer to have the argument be explicit (in type and in name, so that I can see what it is, and what it means), because otherwise whenever I read this code I'm going to think, "ooh, an argument, I wonder what that is" and have to go look it up instead of just being able to see it. If you only provide the type ( |
|
Got it, thanks for the explanation. I'll update the pull request soon.
Alan
…On Fri, Dec 15, 2017, 6:39 PM Ian Hickson ***@***.***> wrote:
Flutter's codebase is intended to be fully typed, so that we don't rely on
inference or dynamic. It has frequently helped us catch bugs.
I prefer to have the argument be explicit (in type and in name, so that I
can see what it is, and what it means), because otherwise whenever I read
this code I'm going to think, "ooh, an argument, I wonder what that is" and
have to go look it up instead of just being able to see it.
If you only provide the type (.thenAnswer(Invocation _)) then I'll wonder
what the argument is supposed to mean ("is it the "before" invocation? Is
it the "answer" of "thenAnswer"? etc). If you only provide the name (
.thenAnswer(invocation)) then I'll wonder what the type of the argument
is. Is it a string? Is it an Invocation? Is it some custom object that is
special for "thenAnswer"?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13521 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACH0ZyG7pfYAVZy8ZCt7DdvV3RHiOLcAks5tAy1tgaJpZM4Q_kUO>
.
|
|
@Hixie friendly ping. Would love to get this merged and pulled into g3 ASAP. |
|
Thanks!
|
|
Thanks! |
* Change async stubbing to use thenAnswer. Mockito now prohibits calling thenReturn with Futures and Streams. dart-lang/mockito#79 * Update all Mockito deps to 3.0.0. * Revert "Update all Mockito deps to 3.0.0." This reverts commit e8ab9d3. I did not correctly update the mockito dep, and there's no easy way to update to 3.0 alpha right now. * Change thenAnswer((_) => to thenAnswer((invocation) => * Add Invocation type to thenAnswer lambdas
Mockito now prohibits calling thenReturn with Futures and Streams. dart-lang/mockito#79