git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Chandra Pratap via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Chandra Pratap <chandrapratap3519@gmail.com>,
	Chandra Pratap <chandrapratap376@gmail.com>
Subject: Re: [PATCH v3] tests: move t0009-prio-queue.sh to the new unit testing framework
Date: Fri, 19 Jan 2024 21:31:41 -0500	[thread overview]
Message-ID: <20240120023141.GA610247@coredump.intra.peff.net> (raw)
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:

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


  parent reply	other threads:[~2024-01-20  2:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-14  8:10 [PATCH] tests: move t0009-prio-queue.sh to the new unit testing framework Chandra Pratap via GitGitGadget
2024-01-14  8:15 ` Chandra Pratap
2024-01-14  8:18 ` [PATCH v2] " Chandra Pratap via GitGitGadget
2024-01-16 16:36   ` Junio C Hamano
2024-01-17  6:01   ` Josh Steadmon
2024-01-17 14:38   ` [PATCH v3] " Chandra Pratap via GitGitGadget
2024-01-17 21:52     ` Junio C Hamano
2024-01-17 21:58     ` Junio C Hamano
2024-01-17 22:15       ` Junio C Hamano
2024-01-20  2:31     ` Jeff King [this message]
2024-01-20 14:23     ` Phillip Wood
2024-01-21 19:28     ` [PATCH v4] " Chandra Pratap via GitGitGadget
2024-01-22 19:09       ` Junio C Hamano
2024-01-22 22:42         ` Jeff King
2024-01-25 20:02       ` [PATCH v5] " Chandra Pratap via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240120023141.GA610247@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=chandrapratap3519@gmail.com \
    --cc=chandrapratap376@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).