Have a way to reset a stubbed mock number of calls

[fredo514]

Hi,

I have a use case where I need to ignore a function call a bunch of times, then attach a stub for which I need to sequence the return value. My solution was to make an array of return values and index into it with the nbCalls parameter, but I can't easily set it up, since I don't know how many time the function has been called before.

Re-registering the stub doesn't seem to reset the count.

It would be really useful to have an explicit function to reset a given function's mock number of calls, or at least reset it by registering the stub again.

Thanks,

[Letme]

Why cant you add Expect() in a for loop? You can have IgnoreArg option if you dont want it to enforce (check) arguments of that function call.

[fredo514]

Because the call count is still incremented, causing my return value array to be very large, much larger than needed.

Also, since the number of calls before my test case is not always the same, I also need to keep a manual counter in the stub to access the number of calls so far, to setup my test case return values at the right location.

[mvandervoord]

If you're using the test runner generator, it will automatically generate a resetTest function for you. This will do what you're looking for.

If you're writing your own test runners, you can get the same behavior by calling MockBlah_Verify(), MockBlah_Destroy and MockBlah_Init for each mock (where Blah is the filename for this particular collections of mocks).

I think that's what you're looking for?

I share in @Letme 's concern: Your reasoning makes me fear that you're writing tests that are too brittle and complex. If you're writing a test which includes variability like this, it's likely not a good test. Indeterminate tests usually lead to indeterminate ability to catch bugs. We, of course, could be misunderstanding the situation as you've described something without a lot of context... but I think it's worthwhile to note that this sort of need in testing is USUALLY a "code smell" and suggests there might be a better way to handle the situation.

[fredo514]

Not quite, I was talking of only a way to reset a given function’s mock number of calls, not re-init the entire module mock. Does ‘resetTest’ verifies the ´expects’ so far or discards them?

I’m actually trying to not to make my tests brittle. To be fair, the number of calls before is usually the same, it’s just that I don’t care about them: the module is an external device driver that requires a lot of very specific SPI calls to setup and operate. My unit test only test focuses only on some logic of the driver, like I feel a device driver unit test should. I don’t care about most SPI calls because I have a HIL test for that and I know it works.

In my case, I’m trying to exercise only the error paths, which are complicated to do in HIL. I have to make it return a very specific sequence of successes, data and errors to reach those. ´_Stub’ allows me to do all that (I need it because some registers auto-update in hardware and I have to fake that to avoid infinite loops).

Which brings me to my request. Since ´nbCalls’ is only reset at the the setup of a test case, I have to place my test cases specific return values starting at the 122nd slot of my return array. It makes my tests very brittle as this value may change if I change the initialisation sequence in the future.

It would be much cleaner to have a way to reset ´nbCalls’ say at the end of ´SetUp’ so that I can place my values at index 0 in my test case.

I hope it clarifies things,

[mvandervoord]

Yes, this makes sense. I think I need to mull over how best to add this feature without making it cumbersome. I could see cases where we want to reset the count for a specific function, specific module, or all mocked modules... and cases where we might want to validate that all the previous mocks have been fulfilled vs just clearing the slate, so to speak.

Currently we can handle the cases for ALL mocks using resetTest() (verify and reset) and CMock_Init (just reset). It wouldn't be hard to add an accessor to validate and reset each module (there is already an init for each to just clear). Per function would get more challenging. None are hard. The part that bothers me the most is finding a clean way to support 6 different use-cases without cluttering things further with rarely used features.