Skip to content

Disallow mock.Anything from satisfying missing function parameter - #588

Open
dnathe4th wants to merge 3 commits into
stretchr:masterfrom
dnathe4th:dn-missing-param-anything
Open

dnathe4th wants to merge 3 commits into
stretchr:masterfrom
dnathe4th:dn-missing-param-anything

Conversation

@dnathe4th

Copy link
Copy Markdown

Fixes #587

@dnathe4th
dnathe4th force-pushed the dn-missing-param-anything branch from d306ac3 to c5856b6 Compare April 4, 2018 17:28
Comment thread mock/mock.go Outdated
// normal checking

if assert.ObjectsAreEqual(expected, Anything) || assert.ObjectsAreEqual(actual, Anything) || assert.ObjectsAreEqual(actual, expected) {
expectedAnythingAndRequired := assert.ObjectsAreEqual(expected, Anything) && actual != missing

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One suggestion would be to move away from usage of the string, you could change the missing to var missingArgument = errors.New("(Missing)"), so we will be comparing on error values, and its easy to change output if required. like this function could return error (custom type) and based on it, the output should be formatted.

Comment thread mock/mock_test.go
assert.Contains(t, diff, `(Missing) != mock.Anything`)

}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could add a test case for Arguments([]interface{}{}).Diff(Arguments([]interface{}{Anything})), expected is missing

@dnathe4th

Copy link
Copy Markdown
Author

How about removing the missing string sentinel all together and returning a new error outright? I kept this new check inside the loop rather than before it in case there are additional errors the user should be informed about.

Comment thread mock/mock.go Outdated
actual = "(Missing)"
} else {
actual = objects[i]
if len(objects) <= i || len(args) <= i {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dnathe4th We should ideally do this as part of mock.On function, and we need to consider varargs, and have to be tested extensively, lets create an issue and raise PR separately. I would suggest just with previous commit along with test case would be good to close the PR.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I replied on #587 I am not sure it is possible to do this check as part of mock.On because there is no way for a function on *mock.Mock to be aware of what struct has embedded it as far as I could tell.

Functionally these two should be the same, but if you like the previous commit better with the extra checks in the conditional at the end I can revert back to that. This version seems strictly better to me from a readability perspective since it has an explicit check on arg length.

From my digging through the existing tests and my understanding of the reflect package, it doesn't seem like varargs needs any special handling since tests like Test_Mock_On_WithMixedVariadicFunc pass on this PR, but maybe I am misunderstanding what is needed here.

@devdinu devdinu Apr 11, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, checked varargs are passed as slice, so we're good.

lets just pull this out of loop, or print it only once when required. you could also add a test to assert the output for this case.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though this is inside the loop it should only print once because I return early. I implemented it like this do the differences counter would still return the total number of errors against the mock, which seemed more correct than returning before the loop with a return value of differences=1

If you feel strongly I can pull it outside the loop.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @devdinu , where did we end up on this? Is this change only acceptable with the check before the loop?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dnathe4th The change looks good. @ernesto-jimenez could help in merging this.

@ernesto-jimenez ernesto-jimenez left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we simplify the logic here?

If we are going to short-circuit the loop when it goes beyond the length of either of the arrays. Could we:

  • Check for inconsistent arity before the loop
  • Remove maxArg and iterate through len(args)
  • Remove the length checks

The main issue is that we would miss wether the other arguments matched.

An alternative might be that we keep the loop as it is, add a couple of bool variables: actualMissing and expectedMissing, and use them on the normal checking.

@dnathe4th
dnathe4th force-pushed the dn-missing-param-anything branch from 7c43fea to ac602de Compare June 12, 2018 23:21
@dnathe4th
dnathe4th force-pushed the dn-missing-param-anything branch from ac602de to 546639c Compare June 12, 2018 23:23
@dnathe4th

Copy link
Copy Markdown
Author

I submit for your review a slight modification to your suggestion @ernesto-jimenez, instead iterating to the shortest argument length, and then checking arity after the loop. This way the existing parameters can all still be compared. This also has the benefit of no longer needing many of those inner conditionals related to the "missing" strings.

@dnathe4th

Copy link
Copy Markdown
Author

Hm that travis-CI failure looks unrelated to my change. Any recommendations there?

@dnathe4th

Copy link
Copy Markdown
Author

Hey team, how can I move this forward?

@dolmen dolmen added bug pkg-mock Any issues related to Mock must-rebase labels Jul 31, 2023
@dolmen

dolmen commented May 12, 2026

Copy link
Copy Markdown
Collaborator

This seems still relevant as of 37a3cb7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug must-rebase pkg-mock Any issues related to Mock

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mock does not enforce arity if parameter is Anything

4 participants