Coder Social home page Coder Social logo

Comments (5)

srawlins avatar srawlins commented on July 20, 2024

WDYT @TedSander @matanlurey

from mockito.

matanlurey avatar matanlurey commented on July 20, 2024

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 🦆

from mockito.

TedSander avatar TedSander commented on July 20, 2024

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.

from mockito.

chalin avatar chalin commented on July 20, 2024

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

from mockito.

srawlins avatar srawlins commented on July 20, 2024

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

from mockito.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.