New Dart 2 semantics Mockito API about mockito

[srawlins]

WDYT @TedSander @matanlurey

[matanlurey]

Thanks for starting this discussion!

I'd love to see some input from @leafpetersen and @munificent too for long-term-isms.

We need to bump Mockito to be Dart 2-only, so that we can remove the pesky typed wrapper, so that everything is just any, argThat, captureArg, etc.

👍

However, the new Mockito API will kind of have to adhere to the typed shortcoming of having to name named arguments by name, i.e. fn(argThat(equals(3), number: argThat(equals(7), named: 'number')). Boooo. Alas, this is unavoidable until we go to a code-genned Mockito, which is a bigger migration than this, and is not necessary until non-nullable types.

Which leads us to: how do we call any and captureAny, which are getters today, and have such marvelous ergonomics, when used with a named argument? 😦 Getters cannot take arguments.

Option A: We split the methods

Null get any => ...
Null anyNamed(String named) => ...
Null get captureAny => ...
Null captureAnyNamed(String named) => ...

This adds confusion because now named is a positional arg in anyNamed and captureAnyNamed, but a named arg in argThat and captureThat. 😦 (Option A2 can be where anyNamed and captureAnyNamed use a named argument for named.)

Yeah, this feels like it "fights" with the type system (though I get that it does today already).

I tried it out on a scratchpad:

main() {
  var foo = new MockFoo();
  when(foo.eat(any)).thenReturn(true);
}

and

main() {
  var foo = new MockFoo();
  when(foo.eat(any, andDrink: anyNamed(#andDrink)).thenReturn(false);
}

Overall it doesn't feel much worse that the current API, and greps a little better. I also like the fact that it looks like it supports incremental migration better than Option B.

Option B: we force any to no longer be a getter, ever 😦 :

Null any({String named}) => ...
Null captureAny({String named}) => ...

This would mean using fn(any(), any(), any()) everywhere. Worse ergonomics, and really confusing and frustrating for people during migration.

This seems more confusing to me than option A, and is a breaking change. I'm not against it, but I'd vote for option A if I get a vote 👎

Option C: Ugh, we go to codegen now

I don't want to do this. It will be huge migration, make Mockito harder to use where codegenning isn't super easy and streamlined, take longer, ... But it does remove the need to use named everywhere.

If/when code-generation is first-class (or at least a "classy" second-class with build_runner V2), I could see requiring code generation for Mockito to be OK. Until then, it seems icky. Though, I wouldn't oppose experimenting with allowing both, for example:

import 'package:mockito/mockito.dart';

part 'example.g.dart';

void main() {
  var foo = new MockFoo();
  when(foo.doThing()).thenReturn('Hello World');
  print(foo.doThing()); // Hello World

  // Entirely made-up API, similar to built_value.
  var bar  = new MockBar((c) => c.doThing().thenReturn('Hello World');
  print(bar.doThing()); // Hello World
}

// Old-style Mock.
class MockFoo extends Mock implements Foo {}

// New-style Mock.
class MockBar implements Bar {
  factory MockBar(void fn(_$MockBarController c)) = _$MockBar;
}

---

Is there an 'Option D': Do nothing, keep the current API, while designing an Option C-like replacement with the language team? Not saying this is the best option, but I like more options 🦆

[TedSander]

I vote A or A2.

I'd like to hold off on C unless there is someone EXTREMELY motivated to work and own the complete solution. Even then I would be a bit hesitant because I don't think we need another migration, and the benefits are not very large for the end user. Mostly mockito just works with a bit of pain for named arguments which aren't the 80% use case.

[chalin]

Given #85, I guess that choices have been made. I'm eager to see this land.

[srawlins]

This has been released in 3.0.0-beta, in #115.