-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mock Matcher for functional options #997
Comments
We're happy to accept PRs and help you get them reviewed :) Out of curiosity, does the https://github.com/vektra/mockery package work in your use case? |
Thanks for pointing to mockery, but I think it is inherently hard to test functional options, since the values are themselves (inner) functions and thus the need for reflection and some runtime magic :) I'm however interested in what would be a reasonable approach to asserting these arguments (provided a function to test equality exists) - either a new Argument type so a new path can be asserted here or perhaps if I'll try to submit a PR to covey my intent (after the next fortnight). |
Sorry for getting back a bit late. Filed #1023 to better demonstrate my idea. |
Hi,
In most go libraries nowadays (etcd, kubernets, aws, etc.) the functional options pattern is being used:
The mocks for these functional options are unfortunately unable to match since the option usually is implemented so:
testify.Mock
matcher will not matchx := WithTimeout()
withy := WithTimeout()
since these are actually distinct functions. Usingmock.AnythingOfType
defeats the purpose since these options are usually significant and even critical to behavior.As a workaround currently, I'm using reflection and the
Call.Run()
(alt.mock.MatchedBy
) function to match theseopts
and log a proper diff (different options, different type, wrong values, etc.). I thought about it and it would've been ideal if we can introduce a matcher typemock.OptionTypeArgument
or something since the MatchedBy func is inadequate for printing meaningful diffs as it will only true/false info of the failure scenario.Is this something that the library could/should support? If yes, I can open a PR to elicit the approach.
The text was updated successfully, but these errors were encountered: