Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 22 16:33
    mabati opened #379
  • Mar 15 09:24
    JolanBrizard opened #378
  • Mar 06 19:58
    mochrul opened #377
  • Mar 05 19:58
    vzuevsky commented #248
  • Feb 19 16:41
    SDAChess commented #376
  • Feb 19 16:10
    SDAChess commented #376
  • Feb 19 16:08
    SDAChess commented #376
  • Feb 19 15:24
    SDAChess opened #376
  • Feb 07 15:40
    borjasotomayor commented #301
  • Feb 06 18:44
    Sombre0mbre opened #375
  • Feb 05 20:49
    xfbs opened #374
  • Feb 04 10:04
    MrAnno edited #301
  • Feb 04 09:59
    MrAnno commented #301
  • Jan 29 20:16
    HugoGDRM commented #223
  • Jan 27 21:01
    abkarcher closed #373
  • Jan 27 21:01
    abkarcher commented #373
  • Jan 27 20:31
    Snaipe commented #373
  • Jan 27 20:31
    abkarcher edited #373
  • Jan 27 20:30
    abkarcher edited #373
  • Jan 27 19:57
    abkarcher opened #373
Franklin Mathieu
@Snaipe
this means that you need at least two parameters
so mmk_mock_create("realloc@libc", mock_id)
for instance
Dominik
@kaidowei
yeah, so in summary:
  • I save 1 parameter at _create
  • I do not need to carry mmk_mock m around
  • I have 1 parameter less at mmk_expect
don't think it's so bad :)
Franklin Mathieu
@Snaipe
somethink like that, yeah
there are still some quirks, mostly in the definition part, but it's acceptable
Other API styles should also be explored
I'd like to test out cmocka's style where you implement your stub with macros
Dominik
@kaidowei
okay. I don't like their style very much, because normally the body of a mocking function is always the same and if you need some special syntax, you can still use a custom stub
do you want to use their --wrap approach too or use your stubs?
Franklin Mathieu
@Snaipe
our stubs
but if we implement something like that, it will probably be the same line-wise
Dominik
@kaidowei
yes.
What still is not ideal: we still generate a mock for every function, even if we don't use an external generator
Franklin Mathieu
@Snaipe
something like
static void *realloc_mock(void *ptr, size_t size) {
    mmk_mock_start;
    mmk_expect(NULL, ptr == NULL, size == 42);
    mmk_mock_end;
}

we still generate a mock for every function

Explain? I don't really see why that's an issue

Oh, wait, I got it
Dominik
@kaidowei
more like? :)
static void *realloc_mock(void *ptr, size_t size) {
    return mmk_expect(NULL, ptr == NULL, size == 42);
}
Franklin Mathieu
@Snaipe
probably not, you can't chain these statements
You should be able to do something like
static void *realloc_mock(void *ptr, size_t size) {
    mmk_mock_start;
    mmk_expect(NULL, ptr == NULL, size == 42);
    mmk_expect(NULL, ptr == (void*) -1);
    for (size_t i = 0; i < 10; ++i) {
        mmk_expect(NULL, size == i);
    }
    mmk_mock_end;
}
Dominik
@kaidowei
okay, the generate thing:
I can't somehow say, "mock everything inside this lib/header" not a big problem, but might be annoying for big libs
that could work (with some internal state, declaring a bool var, setting it when first called, then returning)
Franklin Mathieu
@Snaipe
How would "mock everything" work? You can't possibly define the behaviour of all functions regardless of their prototype and semantics
I've not even seen this in production tests
Dominik
@kaidowei
but with this approach you have a mock for every test. if my first test needs the first call to check for 42 and the second for 13, I have to define two mocks for the same function
yes, I still have to fill in the values for all functions, that get called, but I'd like to avoid writing mmk_declare for every function
Franklin Mathieu
@Snaipe
You don't have mmk_declare, that's the thing
in terms of line, it's about the same to be honest, you still have to do it somewhere
whenever it's inside a function or your test isn't that much important
Dominik
@kaidowei
yes, the generate thing was meant for the current approach
Franklin Mathieu
@Snaipe
the big plus here is that this API is lightweight, and you don't need to do some massive hacking with offsets to compare actual and expected values
you simply pass a predicate that references the parameters
Dominik
@kaidowei
I guess, we could make both work together
Franklin Mathieu
@Snaipe
that could be counterproductive
Dominik
@kaidowei
well, both have limitations
the second works for ... functions
Franklin Mathieu
@Snaipe
right, variadics work out of the box here
however the handling of void-returning functions is moved to mmk_expect
since mmk_expect takes in a hard value to return
you'd need to have a mmk_expect and mmk_expect_and_return
or something of that flavor
I guess, to be fair, that there could be some convenience functions of the sort for the stub API rather than the mock API
you could also decouple the return value from mmk_expect
Franklin Mathieu
@Snaipe
which means you'd have
static void *realloc_mock(void *ptr, size_t size) {
    mmk_mock_start;
    mmk_expect(ptr == NULL && size == 42);
    mmk_return(NULL);
    mmk_expect(ptr == (void*) -1);
    mmk_return(NULL);
    for (size_t i = 0; i < 10; ++i) {
        mmk_expect(size == i);
        mmk_return(NULL);
    }
    mmk_mock_end;
}
this fixes the problem of the void-returning function handling
but it also a whole lot more verbose
Dominik
@kaidowei
hmm that seems a bit overkill
Franklin Mathieu
@Snaipe
I'm not that much of a fan, yeah
Dominik
@kaidowei
mmk_expect and mmk_expect_return and mmk_return should be enough