Snaipe/Criterion

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

Franklin Mathieu

@Snaipe

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

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;
}

Where communities thrive

People

Repo info

Activity