Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Sep 24 14:27
    lazy-dude opened #390
  • Sep 24 13:44
    lazy-dude opened #389
  • Sep 22 21:14
    hl037 opened #388
  • Sep 12 03:11
    2LeoCode closed #387
  • Sep 12 02:47
    2LeoCode opened #387
  • Sep 04 11:29
    Noman5237 closed #385
  • Sep 02 21:17
    Noman5237 closed #386
  • Sep 02 21:17
    Noman5237 commented #386
  • Sep 02 20:49
    Noman5237 opened #386
  • Sep 02 20:39
    Noman5237 opened #385
  • Sep 02 11:18
    talentless-script-kiddie commented #229
  • Sep 02 11:00
    talentless-script-kiddie commented #229
  • Aug 26 16:36
    junglie85 opened #384
  • Aug 24 23:49
    CamJN commented #383
  • Aug 24 03:23
    CamJN opened #383
  • Aug 20 17:09
    CamJN opened #382
  • Aug 10 22:55
    margaretdax commented #212
  • Aug 05 12:33
    cacharle closed #381
  • Aug 05 12:31
    cacharle edited #381
  • Aug 05 12:30
    cacharle commented #381
==743== 568 bytes in 1 blocks are still reachable in loss record 2 of 2
==743==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==743==    by 0x50C2D41: fdopen@@GLIBC_2.2.5 (iofdopen.c:138)
==743==    by 0x4E42713: pipe_in (pipe.c:46)
==743==    by 0x4E43B00: cr_get_redirected_stderr (redirect.c:62)
==743==    by 0x401FDA: another_suite_test_stdout_impl (test_all.c:44)
==743==    by 0x4E425C5: criterion_internal_test_main (test.c:56)
==743==    by 0x4016EA: another_suite_test_stdout_jmp (test_all.c:37)
==743==    by 0x4E3F6F8: run_test_child (runner.c:180)
==743==    by 0x4E41808: run_worker (worker.c:84)
==743==    by 0x4E4193C: spawn_test_worker (worker.c:111)
==743==    by 0x4E40FCE: run_test (runner_coroutine.c:66)
==743==    by 0x4E41506: run_next_test (runner_coroutine.c:162)
   match-leak-kinds: reachable
Franklin Mathieu
oh, right
static void redirect_all_std(void) {

Test(another_suite, test_stdout, .init = redirect_all_std) {
    fprintf(stdout, "foo");

    fprintf(stderr, "bar");
and the other one....
Franklin Mathieu
I think I forgot to close both file handles, so it's (kinda) normal
and yeah, 2nd memleak has been fixed on bleeding
ah okay. But I guess we will not switch to bleeding :D
Franklin Mathieu
yeah, not yet though
I'll cherry pick the fix on the patch branch
plans for 2.2.1?
Franklin Mathieu
2.2.1 will be released this saturday if everything goes right
Franklin Mathieu
@kaidowei I experimented a bit more with the 1rst API draft and came up with this: http://pastebin.com/raw/dkCKD4YY
This possible 2nd draft should be more adequate than the first for mocking
(the syntax is inspired by mockito)
I haven't got the time to really make a full implementation, but it seems to be possible from the few tests I ran
I am also hesitating on the syntax of mmk_when


mmk_when (malloc, m,
            .with_size = mmk_eq(size_t, sizeof (ref)),
            .then_return = buf);

of course, but

mmk_when (m, malloc(sizeof (ref)), .then_return = buf);

seems really attractive

The biggest obstacle against syntax 2 are sequence points
Franklin Mathieu
but I think I might be able to bypass it with some macro magic and __COUNTER__.
this also opens the door to over the top control over parameter conditions
because then you could have easily something like:
mmk_when (m, foo(1, mmk_lt(0), mmk_arg_that(is_valid)), .then_return = 42);
and specify whatever matcher you want
just to be clear: mmk_when adds a call and verify checks, if that call was made?
Franklin Mathieu
mmk_when binds a combination of parameters to a return value, mmk_verify checks whenever a function was called or not
so when I have a function that calls my mock 10 times, I have to write mmk_verify 10 times?
can't you verify in the stub?
Franklin Mathieu
@kaidowei you would do mmk_verify(..., .times = 10)
mmk_verify lets you check the number of times a function has been called based on predicates
okay, I see. But why do I have to pass the same information again? Cant the mock do that work?
Franklin Mathieu
What do you mean by same information?
Are you talking about mmk_when vs mmk_verify?
yes. mmk_when tells the mock how often and how it will be called;
mmk_verify should only check whether the mock really was called that way
Franklin Mathieu
Actually, it's a bit more subtle than that. mmk_when defines the behaviour of the mock regardless of the number of times the stub is called. If you define foo(1) to return 1, then it will always do so.
mmk_verify asserts that at some point the function has been called with matching parameters a certain number of times
Both are complementary but not necessary to each other
If you want to test what happens when a function returns a specific value, you use mmk_when (i.e. you tell a function to do things)
If you want to test how the function has been used (i.e. you ask the function if it has been called the way you want), then you use mmk_verify
You can completely use mmk_verify without mmk_when, and mmk_verify without mmk_when (useful when you don't care about return values)
Franklin Mathieu
Er, I meant mmk_when without mmk_verify
okay, I understand. powerful, but (at first glance) quite confusing
what does mmk_eq do?
Franklin Mathieu
mmk_eq ought to dissappear, I've since found a better way to express it
ah, good
Franklin Mathieu
but in theory it's a matcher that fixes a parameter to the specific value
in my new batch of tests, it's simply .with_foo = 42 instead of .with_foo = mmk_eq(type, 42)
there are other matchers though
like mmk_any(type), which produces a dummy value matching any parameter
or mmk_lt(type, val), which produces a dummy value matching any parameter less than val