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
next prev parent 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).