Offer an easy way to ignore named parameters about mockito

[srawlins]

Yes, it should.

[srawlins]

I agree this is annoying. I recently converted a lot of code that used the deprecated mock package to use mockito. The mock package is much looser about function arguments, so it was frustrating to migrate to mockito, and then tests don't work until I hunt down the exact method call that I want to match against.

logInvocations and throwOnMissingStub can help situations like this.

However, if you are also referring to the issue where the calling code has all the different variations, your test setUp can have tons of boilerplate! Like what if I want to mock HttpRequest.open?

class MockHR extends Mock implements HttpRequest {}

var mhr = new MockHR();
when(mhr.open(any, any)).thenReturn(...);
when(mhr.open(any, any, async: any)).thenReturn(...);
when(mhr.open(any, any, user: any)).thenReturn(...);
when(mhr.open(any, any, password: any)).thenReturn(...);
when(mhr.open(any, any, async: any, user: any)).thenReturn(...);
when(mhr.open(any, any, async: any, password: any)).thenReturn(...);
when(mhr.open(any, any, user: any, password: any)).thenReturn(...);
when(mhr.open(any, any, async: any, user: any, password: any)).thenReturn(...);

Ugh!

We could maybe introduce a looser mocking call, a sibling to when. Maybe whenLoosely or whenSomethingLike? Or maybe another intermediate call like when(mhr.open(any, any)).dontworryaboutotherargumentsthough.thenReturn(...).

WDYT @matanlurey

[xster]

logInvocations definitely helps but then it's a bit backwards. You're can't write the expected behaviour in a test first then do the implementation. It's more like running it once then saving a golden. The scoping would mean when you refactor unrelated things, you'll have to keep updating the goldens to match different signatures even though it doesn't affect the real logic you wanted to test.

[srawlins]

Hi @xster, sorry for the long delay. WDYT about my two ideas? Either

whenLoosely(obj.a()).thenReturn(...);

// or 

when(obj.a()).dontworryaboutotherarguments.thenReturn(...);  // choose a better name.

// or more of a structured looseness

when(obj.a()).andAnyOptionalArgs.thenReturn(...);
when(obj.a()).andAnyNamedArgs.thenReturn(...);

[xster]

Seems like the toggle is a property of the 'when'-ness than of the Expectation. Perhaps when(someCall, {MatchMode matchArguments})? Then it's semantically succinct and also discoverable.

[srawlins]

I can see that.

when(obj.func(...), matchMode: MatchMode.ignoreArgs).thenReturn...
when(obj.func(...), matchMode: MatchMode.onlyRequiredArgs).thenReturn...
when(obj.func(...), matchMode: MatchMode.exactArgs).thenReturn... // default

WDYT @matanlurey @TedSander ?

[TedSander]

SGTM

[xster]

LG!

Just to understand the nuance between the first 2, given:

void a(B b, {C c, D d});

what would

when(obj.a(anInstanceOfB, c: anInstanceOfC), matchMode: MatchMode.ignoreArgs vs MatchMode.onlyRequiredArgs).thenReturn

do differently? Would MatchMode.ignoreArgs also match an actual invocation obj.a(null, null, null)?. Would MatchMode.onlyRequiredArgs also match obj.a(b, null, null)?

[srawlins]

ignoreArgs would match on anything, regardless of the anInstanceOfB and anInstanceOfC. onlyRequiredArgs would require anInstanceOfB to match, but not c nor d. If a call comes in that matches anInstanceOfB, then the same ordering rules that Mockito uses today would apply.

ignoreArgs would allow one to put in a bunch of nulls.

onlyRequiredArgs would also match b, c: null, d: null.

[xster]

SG

[patkujawa-wf]

I think ignoreArgs and onlyRequiredArgs are ambiguous. What if you have ignore but then supply some args in the call? Should it ignore the ones you've supplied?

And onlyRequired implies that positional args are required but keyword are not, but folks using meta's @required would expect kwargs to be required too.

How about just 2 states, to start:

1. exact, the default, which doesn't change any behavior
2. ignoreExtra which matches on supplied args but doesn't fail if additional args were passed to the call
   (I removed the Args suffix because it felt redundant - perhaps the param and enum could be named [aA]rgsMode instead.)

It would be really nice, too, to globally set the mode to ignoreExtra, because we would do that in all of our projects.

[srawlins]

This feature isn't going to be written, because it's largely been replaced by the noSuchMethod Forwarding feature of Dart 2.0.0-dev.56ish+ (see #122).

Basically, noSuchMethod will receive default values for optional (and optional named) parameters (of course, this happens during when, real calls, and verify), which solves @xster 's original request, and my HttpRequest.open example.

Mockito basically no longer has the power to see if an argument was passed or not (similar to how a method generally cannot tell if a default argument was used, or if an explicit argument, equal to the default value, was passed).

[patkujawa-wf]

So when we upgrade to dart 2 the behavior will just default to be like ignoreExtra?