On Wed, Jan 17, 2024 at 02:38:23PM +0000, Chandra Pratap via GitGitGadget wrote:
> +#define TEST_INPUT(INPUT, EXPECTED, name) \
> + static void test_##name(void) \
> +{ \
> + int input[] = {INPUT}; \
> + int expected[] = {EXPECTED}; \
> + int result[ARRAY_SIZE(expected)]; \
> + test_prio_queue(input, result); \
> + check(!memcmp(expected, result, sizeof(expected))); \
> +}
It is somewhat unfortunate that a failing test here gives a fairly
uninformative message like:
# check "!memcmp(expected, result, sizeof(expected))" failed at t/unit-tests/t-prio-queue.c:89
not ok 5 - prio-queue works when LIFO stack is reversed
whereas the original t0009 you get a nice diff between expected and
actual output. I guess this is a place where the test framework could
help us more with a specialized check_memequal() or something that
showed the differing bytes on failure (of course being C, it has no type
info so it wouldn't even know these are ints!).
Another solution would be to have the test function check the result as
it is computed rather than storing it in an array. That would also solve
another potential problem: undefined behavior if the result is not the
expected size. If there is a bug that causes too much output we'd
overflow our buffer. If too few, we'll end up comparing uninitialized
memory (which could even accidentally have the correct values,
especially if it's recycled from a previous test!). Neither of those
should happen in practice, but then the whole point of this exercise is
to test the code.
I admit I find myself a little skeptical in general of this whole "let's
do tests in C" framework.
-Peff
