Closed qdm12 closed 2 years ago
Because of how validation and stuff works on the mock today I think it is best if they mocks are made per-subtest. They are not really meant to be reused today. I think that would be a feature in itself. The parallel bit would make things tricky. There are assumptions made with mock internals that would make this challenging.
Makes sense :+1: Actually using mock builder fields in test cases does the trick in some way, where you configure the mock in a function taking a controller as argument (at least). I wrote some gist about it here if that can be of any interest to anyone. Anyway, thanks for the feedback!
Requested feature Allow the user to configure mocks before the actual (sub)test and hence without passing
*testing.T
to a controller. The*testing.T
could be passed within the subtest instead, perhaps at the start of it.Why the feature is needed For now the only way to manage mocks with subtests is to have the controller defined within the subtest. Some developers prefer to configure all the 'state' before launching the subtests in a for loop iterating over test cases. The problem is having the controller defined in the parent test:
Production code:
Test code:
Will result in
And further test cases (1,2,3,4) will not run because the parent test got failed within a subtest.
(Optional) Proposed solution A clear description of a proposed method for adding this feature to gomock.
I would propose the following, but I'm happy to discuss other options, and maybe it's not feasible at all.
nil
controller toNewMockController
RegisterT(t *testing.T)
on the controller to register at *testing.T
. This would be called in subtests for example.*testing.T
field, whenever the controllerCall(...)
orRecordCall(...)
method is called. If it's not set, panic.One could also replace this
nil
*testing.T
by a custom type implemetinggomock.TestReporter
such as*gomock.DelayedT
for example.Regarding parallel tests, it should be ensured a particular mock is not called in more than one subtest when running them in parallel. This is the part that might be a bit tricky to handle and may make the whole thing not viable.
With these changes, you could then have: