Re: [PATCH v3] tests: move t0009-prio-queue.sh to the new unit testing framework

From: Jeff King <peff@peff.net>
Date: Jan 20, 2024, 02:31 UTC
Message-ID: <20240120023141.GA610247@coredump.intra.peff.net>
In-Reply-To: <pull.1642.v3.git.1705502304219.gitgitgadget@gmail.com>

On Wed, Jan 17, 2024 at 02:38:23PM +0000, Chandra Pratap via GitGitGadget wrote:

Show 9 quoted lines

> +#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