Ability to disable the automatic call to Controller.Finish, such that the test does not fail if expected mocked calls are not made.
Why the feature is needed
Reinstate (and make explicit/official) support for "stub" style tests that use the mock framework to stub out interactions with collaborators, but where verifying the occurrence of those calls is out of the test's intended scope.
I've discussed with @codyoss in https://github.com/golang/mock/issues/584. As noted there, on versions 1.5.0 and earlier, you could simply omit the explicit call to Controller.Finish and get the behavior described here. However, the addition of an implicit call in 1.6.0 broke tests that worked that way.
The current documented alternative is to suffix every mock expectation with .AnyTimes(), but that's quite boilerplate-heavy and undesirable when undertaking this test design approach widely.
Proposed solution
Allowing options to NewController is proposed in https://github.com/golang/mock/issues/238, and seems like a reasonable way to meet this need (as well as others, which could be added at whatever point).
A workable alternative, though perhaps less compelling, would be to express this variability in the form of an alternative to NewController, e.g. NewStubController. This would return something that works just like Controller but doesn't call Finish for you.
Another idea would be to call a method on an existing Controller instance to explicitly disable the automatic call -- e.g. ctrl.NoFinish(), ctrl.NoVerify(), or ctrl.Stub().
Any of these would work fine for me, as would other approaches as long as they're concise rather than the boilerplate-heavy status quo of calling .AnyTimes() all over the place.
Requested feature
Ability to disable the automatic call to
Controller.Finish, such that the test does not fail if expected mocked calls are not made.Why the feature is needed
Reinstate (and make explicit/official) support for "stub" style tests that use the mock framework to stub out interactions with collaborators, but where verifying the occurrence of those calls is out of the test's intended scope.
I've discussed with @codyoss in https://github.com/golang/mock/issues/584. As noted there, on versions 1.5.0 and earlier, you could simply omit the explicit call to
Controller.Finishand get the behavior described here. However, the addition of an implicit call in 1.6.0 broke tests that worked that way.The current documented alternative is to suffix every mock expectation with
.AnyTimes(), but that's quite boilerplate-heavy and undesirable when undertaking this test design approach widely.Proposed solution
Allowing options to
NewControlleris proposed in https://github.com/golang/mock/issues/238, and seems like a reasonable way to meet this need (as well as others, which could be added at whatever point).A workable alternative, though perhaps less compelling, would be to express this variability in the form of an alternative to
NewController, e.g.NewStubController. This would return something that works just likeControllerbut doesn't callFinishfor you.Another idea would be to call a method on an existing
Controllerinstance to explicitly disable the automatic call -- e.g.ctrl.NoFinish(),ctrl.NoVerify(), orctrl.Stub().Any of these would work fine for me, as would other approaches as long as they're concise rather than the boilerplate-heavy status quo of calling
.AnyTimes()all over the place.