-
Notifications
You must be signed in to change notification settings - Fork 608
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I signed it! |
CLAs look good, thanks! |
I'm not sure about this. This overloads SetArg to also fill a slice, which feels like it's not the same thing. This need shouldn't block anyone because the easy workaround is to use the Do function to fill the slice. However, I could see the value of a function specifically for filling an input slice. |
I think it's morally the same as other uses of SetArg as it does actually
change the input argument.
Happy to implement it as a separate function though; name suggestions?
…On Mon, 14 Aug 2017, 23:20 Hesky Fisher, ***@***.***> wrote:
I'm not sure about this. This overloads SetArg to also fill a slice, which
feels like it's not the same thing.
This need shouldn't block anyone because the easy workaround is to use the
Do function to fill the slice. However, I could see the value of a function
specifically for filling an input slice.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#98 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AATMe764MsJfjLHJZ_U6rLtsD-SdIbppks5sYMgcgaJpZM4O2dRo>
.
|
I agree with @balshetzer that it's better to handle only pointer args in Pointer args are sometimes used as "return values" - probably by ex C programmers - despite the fact that it isn't very idiomatic in go where you can easily return multiple values. Any other case - like modifying an array or any other input object - isn't really like simply returning a value. Modifying an incoming object is a messy business that is better done in The above problems have been discussed in #27. In my opinion
The power of gomock lies in providing only a few very solid features that cover 99% of the testing scenarios. For other edge cases it provides 1 tool - the |
I agree that One of my ideas was extending the current behaviour of If func NewArrayFirstByteZeroer(argName string) func(args map[string]interface{}) {
return func(args map[string]interface{}) {
args[argName].([]byte)[0] = 0
}
} ... and then reusing it would be a breeze: myMock.EXPECT().Whatever().Do(NewArrayFirstByteZeroer("data")) Since the arg names are available only in case of source generation method (and not in case of reflection based) it might make sense to use the |
I guess the more accurate name for |
You can't set an array/slice arg, you can only modify it. I wouldn't put any new "features" into gomock other than improving |
@hatstand I've thought about it and would like to accept this PR. Would you be willing to add unit tests and update the comment on SetArg to explain what it does? @pasztorpisti I hear your points too but populating arg slices is clearly something that is done in Go and so, I think, having SetArg "do the right thing" for slices seems like it will make it more useful without much cost. |
Populating arg slices usually involves complex logic (which is basically simulating the mocked logic - something for which |
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that they're okay with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
CLAs look good, thanks! |
Added documentation & unit tests. |
I needed this while trying to write tests against https://godoc.org/github.com/kidoman/embd#SPIBus
SPIBus::TransferAndReceiveData([]byte)
writes its output back to the input byte slice.Would also fix #27