Comments (8)
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 _Expect
s would be implictly ignored should generate a runtime error. The ability to have a functional test with _Expect
s 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.
Related Issues (20)
- :strippable question/suggestion HOT 2
- _Expect does not work as expected - with structures HOT 1
- CMock not breaking include chain at mocked header HOT 6
- How to mock local variable HOT 2
- Missing _Expect methods HOT 6
- When CMock is out of memory it does not tell you so HOT 5
- CMock: More control on expectation order - proposal HOT 7
- Cmock: error: invalid application of 'sizeof' to incomplete type 'xxx_t {aka struct xx_s} HOT 5
- [Bug] "Failed Parsing Declaration Prototype!" for different macros HOT 2
- [BUG] Cmock functions are generated incorectlly in some cases HOT 3
- I need ExpectWithPtr mock (?) HOT 1
- Docs don't specify to quote the config file for the -o argument HOT 8
- Expect() mock of function expecting pointer incorrectly dereferences pointer HOT 4
- No function prototypes found in C++ header HOT 3
- ReturnThrPtr,ReturnArrayThrPtr,ReturnMemThrPtr HOT 5
- Additional option to be able to mock global variables
- Only first value of array is checked HOT 2
- Mock generated is wrong when the name of the parameter contains size or length sub-string HOT 1
- new release for CMOCK
- UNITY_TEST_ASSERT_EQUAL_uint8_array is generated instead of UNITY_TEST_ASSERT_EQUAL_UINT8_ARRAY HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cmock.