Snaipe/Criterion

A KISS, non-intrusive cross-platform C unit testing framework

Franklin Mathieu

@Snaipe

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

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

the compiler will see some return foo for a return void function and complain

Dominik

@kaidowei

@Snaipe are you interested in memory leaks for criterion v2.2.0?

Franklin Mathieu

@Snaipe

sure, what do you have ?

Dominik

@kaidowei

{
   criterion redirect pipe
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:fdopen@@GLIBC_2.2.5
   fun:pipe_in
   fun:cr_get_redirected_*
}

Franklin Mathieu

@Snaipe

where is this happenning?

Dominik

@kaidowei

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:alloc_entry
   fun:smalloc_impl
   fun:smalloc
   fun:test_stats_init
   fun:run_next_test
   fun:run_tests_async
   fun:criterion_run_all_tests_impl
   fun:criterion_run_all_tests
   fun:main
}

Franklin Mathieu

@Snaipe

oh, wait, it's a suppression

Dominik

@kaidowei

yeah

I can send you the stacktrace/code too

Franklin Mathieu

@Snaipe

I would rather, cr_get_redirected_* isn't really helpful

I think the second leak has been fixed on patch

Dominik

@kaidowei

==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)
==743== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:fdopen@@GLIBC_2.2.5
   fun:pipe_in
   fun:cr_get_redirected_stderr
   fun:another_suite_test_stdout_impl
   fun:criterion_internal_test_main
   fun:another_suite_test_stdout_jmp
   fun:run_test_child
   fun:run_worker
   fun:spawn_test_worker
   fun:run_test
   fun:run_next_test
}

arg

Franklin Mathieu

@Snaipe

oh, right

Dominik

@kaidowei

static void redirect_all_std(void) {
    cr_redirect_stdout();
    cr_redirect_stderr();
}

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

    fprintf(stderr, "bar");
    fflush(stderr);
    cr_assert_stderr_eq_str("bar");
}

and the other one....

Franklin Mathieu

@Snaipe

I think I forgot to close both file handles, so it's (kinda) normal

and yeah, 2nd memleak has been fixed on bleeding

Dominik

@kaidowei

ah okay. But I guess we will not switch to bleeding :D

Franklin Mathieu

@Snaipe

yeah, not yet though

I'll cherry pick the fix on the patch branch

Dominik

@kaidowei

thanks

plans for 2.2.1?

Franklin Mathieu

@Snaipe

2.2.1 will be released this saturday if everything goes right

Franklin Mathieu

@Snaipe

@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

there's

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

@Snaipe

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

Dominik

@kaidowei

hi
just to be clear: mmk_when adds a call and verify checks, if that call was made?

Franklin Mathieu

@Snaipe

mmk_when binds a combination of parameters to a return value, mmk_verify checks whenever a function was called or not

Dominik

@kaidowei

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

@Snaipe

@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

Dominik

@kaidowei

okay, I see. But why do I have to pass the same information again? Cant the mock do that work?

Where communities thrive

People

Repo info

Activity