git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: git@vger.kernel.org, Denton Liu <liu.denton@gmail.com>
Subject: Re: [PATCH 2/2] test-lib-functions: use BUG() in 'test_must_fail'
Date: Sun, 21 Feb 2021 16:58:23 -0500	[thread overview]
Message-ID: <YDLXf+OoJabrJTWu@coredump.intra.peff.net> (raw)
In-Reply-To: <20210221192512.3096291-2-szeder.dev@gmail.com>

On Sun, Feb 21, 2021 at 08:25:12PM +0100, SZEDER Gábor wrote:

> In many test helper functions we verify that they were invoked with
> sensible parameters, and call BUG() to abort the test script when the
> parameters are buggy.  6a67c75948 (test-lib-functions: restrict
> test_must_fail usage, 2020-07-07) added such a parameter verification
> to 'test_must_fail', but it didn't report the error with BUG(), like
> we usually do.

OK. I do not care all that much between BUG() and not-BUG here, since we
are unlikely to have a test where test_must_fail returning 0 yields
success. I guess the most interesting outcome is that we would notice a
bug in a test_expect_failure block.

> The two tests checking that 'test_must_fail' recognizes invalid
> parameters need some updates:
> 
>   - BUG() calls 'exit 1' to abort the test script, but we don't want
>     that to happen while testing 'test_must_fail' itself, so in those
>     tests we must invoke that function in a subshell.
>   - These tests check that 'test_must_fail' failed with the
>     appropriate error message, but BUG() sends its error message to a
>     different file descriptor, so update the redirection accordingly.

This is a bit intimate with the magic 7 descriptor. I think it would be
cleaner to trigger the bug in a sub-test. We do have helpers for that,
like:

diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index b9d5c6c404..b3fd740452 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -1315,13 +1315,25 @@ test_expect_success 'test_must_fail on a failing git command with env' '
 '
 
 test_expect_success 'test_must_fail rejects a non-git command' '
-	! ( test_must_fail grep ^$ notafile ) 7>err &&
-	grep -F "test_must_fail: only '"'"'git'"'"' is allowed" err
+	cmd="grep ^$ notafile" &&
+	run_sub_test_lib_test_err bug-fail-nongit "fail nongit" <<-EOF &&
+	test_expect_success "non-git command" "test_must_fail $cmd"
+	EOF
+	check_sub_test_lib_test_err bug-fail-nongit <<-\EOF_OUT 3<<-EOF_ERR
+	EOF_OUT
+	> error: bug in the test script: test_must_fail: only ${SQ}git${SQ} is allowed: $cmd
+	EOF_ERR
 '
 
 test_expect_success 'test_must_fail rejects a non-git command with env' '
-	! ( test_must_fail env var1=a var2=b grep ^$ notafile ) 7>err &&
-	grep -F "test_must_fail: only '"'"'git'"'"' is allowed" err
+	cmd="env var1=a var2=b grep ^$ notafile" &&
+	run_sub_test_lib_test_err bug-fail-env "fail nongit with env" <<-EOF &&
+	test_expect_success "non-git command with env" "test_must_fail $cmd"
+	EOF
+	check_sub_test_lib_test_err bug-fail-env <<-\EOF_OUT 3<<-EOF_ERR
+	EOF_OUT
+	> error: bug in the test script: test_must_fail: only ${SQ}git${SQ} is allowed: $cmd
+	EOF_ERR
 '
 
 test_done

This is modeled after other similar tests. I find the use of
check_sub_test_lib_test_err here a bit verbose, but I think we could
also easily do:

  grep "bug in the test.*only .git. is allowed" bug-fail-nongit/err

Note that there are some other cases which could likewise be converted
(the one for test_bool_env, which I noticed when grepping for "7>" when
investigating the first patch).

>  test_expect_success 'test_must_fail rejects a non-git command' '
> -	! test_must_fail grep ^$ notafile 2>err &&
> +	! ( test_must_fail grep ^$ notafile ) 7>err &&
>  	grep -F "test_must_fail: only '"'"'git'"'"' is allowed" err
>  '

Holy double-quoting batman! I do think using $SQ or just "." (if using
grep) to match single-quotes makes things more readable. Obviously not
something you're introducing, but perhaps worth addressing as we touch
this test.

-Peff

  reply	other threads:[~2021-02-21 22:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-21 19:25 [PATCH 1/2] tests: don't mess with fd 7 of test helper functions SZEDER Gábor
2021-02-21 19:25 ` [PATCH 2/2] test-lib-functions: use BUG() in 'test_must_fail' SZEDER Gábor
2021-02-21 21:58   ` Jeff King [this message]
2021-02-22 19:11     ` Jeff King
2021-02-22 19:17       ` Jeff King
2021-02-22 20:02         ` Junio C Hamano
2026-04-14 20:52     ` SZEDER Gábor
2026-04-14 21:11       ` Junio C Hamano
2026-04-14 22:18         ` Jeff King
2026-04-15 15:25           ` Junio C Hamano
2026-04-14 22:14       ` Jeff King
2021-02-21 21:50 ` [PATCH 1/2] tests: don't mess with fd 7 of test helper functions Jeff King
2021-02-22 17:45   ` Junio C Hamano

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=YDLXf+OoJabrJTWu@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=liu.denton@gmail.com \
    --cc=szeder.dev@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).