Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 07 13:26
    MrAnno commented #301
  • May 07 13:08
    hydrapolic commented #336
  • 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
Dominik
@kaidowei
mmk_expect (m, realloc_mock can't you use m to figure realloc_mock out?
Franklin Mathieu
@Snaipe
no unfortunately, because I still need the definition of struct reallocmock_params
(for the compound literal)
Dominik
@kaidowei
I see. If you change the mmk_mock_define to be 1:1 for a function, you could create a mmk_expect_<mymock> for each declaration and the user would not need to carry the m around
mmk_mock_create ("realloc", NULL, realloc_mock) could be reduced to mmk_mock_create(realloc)
Franklin Mathieu
@Snaipe
bad idea
you still need to define what realloc you're changing
Dominik
@kaidowei
what do you mean with "what realloc"?
Franklin Mathieu
@Snaipe
is it the one used by the current program, or the one used by the library, or the one used by the libc?
Dominik
@kaidowei
put the optional path behind realloc
Franklin Mathieu
@Snaipe
there are as many plt addresses for realloc as there are dynamic modules
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