Suggestion: Stub with callback - reset on next Expect about cmock HOT 8 CLOSED

Yes, that's the intended behavior for the counter. It's primarily meant as an index into results arrays, etc. Since C counts everything from 0, it seemed appropriate to stick with that convention.

I'll try to tackle the callback behavior soon. :)

from cmock.

At this point, the two features have already been separated. @bmcdonnell-ionx is correct. If the desire is to have the stub only execute once, then the inside of the stub can disable the stub by reassigning the stub back to NULL. It could also contain custom assertions if desired.

from cmock.

Hi.

This behavior comes from mocking systems in other languages. Usually, a fakes-engine lets you create either a mock or a stub for a particular test. Rarely do you get to do both. If you create a stub, you expect to have to fill it all in by hand. If you create a mock, you expect that the engine is going to do most of the hard work for you.

We already have a bit of a hybrid approach, so continuing to the logical conclusion, as you suggest, might make sense. It might mean separating stub from callback... perhaps callbacks work as you suggest and stubs don't perform any expect checking, etc ever?

How would you see this working? Would you call the _ExpectWithCallback function multiple times with the same argument if you wanted it to get called multiple times in the test? Would it lose the ability to Expect calls first and then perform the callback then?

from cmock.

I would be okay with that. The way I expected it to behave initially was to have the callback be called once, similarly to ExpectAndReturn, but with the count argument in each callback, I realized that this wasn't the case, which made my next conclusion the "until replaced" version.

I guess the most natural behavior would be to have the callback be the only handler of the calls until anything else was specified. The count-checking can (and should) be done in the callback itself, since the count-argument's already there.

As an alternative, an explicit "disable callback" function might make sense, instead of the implicit version I suggested. The implicit disabling of the callback could either complement the explicit version, or result in a test failure. In its current form, it only appears as weird, unexpected behavior in my test, and figuring out what went wrong is hard.

On a similar note, will the callback count parameter be reset each time I reset the callback, or is it strictly increasing for the duration of the test?

from cmock.

Update: checked the count parameter reset behavior, seems like it resets on mock_Init(), which is quite reasonable to me. In the first call, it's 0 though, which is kind of strange.

from cmock.

I like the idea of separating the concept of stubs and callbacks to be a full replacement and a one-time call. I often do have situations where I want to do something fancier with a callback in just ONE particular call (maybe checking for an argument within a particular range, rather than a single value) but not others. However, I also have situations where I use CMock to easily install a full fake implementation of a module (like an EEPROM driver) where I really want the ability to write a single stub that always gets called, without any order or parameter checking beyond what I implement myself.

I'd also suggest that, whatever the case, any situation where _Expects would be implictly ignored should generate a runtime error. The ability to have a functional test with _Expects that end up doing nothing can only lead to confusion and errors.

Something like:

foo.h:

int foo_thing(int arg);

test_uses_foo.c:

#include "mock_foo.h"

int foo_thing_stub(int arg, int cmock_num_prev_calls)
{
    /* do stub things */
}

void test_uses_foo_first(void)
{
    foo_thing_ExpectAndReturn(5, 0);
    foo_thing_StubWithCallback(foo_thing_stub) /* Error because there's already an expected call */
}

void test_uses_foo_second(void)
{
    foo_thing_StubWithCallback(foo_thing_stub)
    foo_thing_IgnoreAndReturn(-1); /* Error because there's already a callback */
}

from cmock.

Is there any plan about implementing the stub/callback separation soon-ish?

from cmock.

I like the idea of separating the concept of stubs and callbacks to be a full replacement and a one-time call.

If I understand correctly, you could achieve the desired one-time stub functionality by using foo_thing_AddCallback(), and wrapping the body inside the callback function with if (cmock_num_calls == 0).

Maybe you'll still need e.g. an Expect to go with the first call. You could ignore the args if you like.

from cmock.