-
Notifications
You must be signed in to change notification settings - Fork 112
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
Allow control over matching order of call expectations #152
Comments
cc: @r-hang |
Hey @thediveo, Thank you for filing the issue. My understanding of the issue is that gomock queue will queue expectations by normal means. Under While I can see how overriding expectations with queuing behavior does allow users to match for call placement I think that something like a Is my description above a sufficient understanding of the issue? |
@r-hang yes, that's also my understanding. The placement idea was initial, to get the discussion going. With some time passed, it doesn't look like correctly addressing the underlying situation. Looking at the situation now, it could be a better solution to allow removing all previously set expectations for a particular receiver in order to register a fresh set of expectations. Kind of an override, but allowing for multiple chained expectations, where the existing override mechanism only allows for a single replacement expectation. At the moment I'm working around the current situation by using optional args in the mock setup, where this args are the names of receiver methods that should not get default expectations. This is somewhat brittle, so I would highly appreciate a better way in the future. For reference, here's my workaround: https://github.com/thediveo/morbyd/blob/4138a6913cae8105b41805515112e303773cec0c/client_test.go#L53 ... I'm using strings in lieu of typed constants which admittedly is more brittle than necessary. |
Requested Feature
Give test spec writers control over the sequence in which call expectations for a specfic 《receiver, method》are processed, in order to allow adding more specific expectations before an earlier set up "catch all" expectations. For instance, by adding
MatchFirst()
andMatchLast()
methods toCall
which then indicate order preference.A test might want to create the mock with default calls that match any args, any time, and that forward the calls to a real implementation, such as a Docker client. While it is possible to replace the default call expectations, it is impossible to replace a single default expectation with a series of expectations matching specific args (see below).
Why the feature is needed
WithOverridableExpectations
always replaces a specific expectation for 《receiver, method》 with a single new one, making it impossible to replace an existing default expectation with a series of expectations.(Optional) Proposed solution
placement
field toCall
.MatchFirst
andMatchLast
methods that set theplacement
of a call, much like the min and max settings.callset.add
to useCall.placement
to either add at the beginning of the matcher list, at the end, or default (which seems to be at the end).The text was updated successfully, but these errors were encountered: