| Message ID | ab542ae9aa35decd2bc55561c5ba8f5653fa07a2.1625362489.git.congdanhqx@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | cdff1bb5a3d6f0e6bf26d8ff088a0e10b40bc4f3 |
| Headers | show |
| Series | new test-libs-function: test_stdout_line_count | expand |
On Sun, Jul 4, 2021 at 1:46 AM Đoàn Trần Công Danh <congdanhqx@gmail.com> wrote: > In some tests, we're checking the number of lines in output of some > commands, including but not limited to Git's command. > > We're doing the check by running those commands in the left side of > a pipe, thus losing the exit status code of those commands. Meanwhile, > we really want to check the exit status code of Git's command. > > Let's write the output of those commands to a temporary file, and use > test_line_count separately in order to check exit status code of > those commands properly. > > Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> > --- > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh > @@ -845,6 +845,32 @@ test_line_count () { > +# SYNOPSIS: > +# test_stdout_line_count <bin-ops> <value> <cmd> [<args>...] > +# > +# test_stdout_line_count checks that the output of a command has the number > +# of lines it ought to. For example: > +# > +# test_stdout_line_count = 3 git ls-files -u > +# test_stdout_line_count -gt 10 ls > +test_stdout_line_count () { > + local ops val trashdir && > + if test "$#" -le 3 > + then > + BUG "expect 3 or more arguments" > + fi && > + ops="$1" && > + val="$2" && > + shift 2 && > + if ! trashdir="$(git rev-parse --git-dir)/trash"; then > + BUG "expect to be run inside a worktree" > + fi && > + mkdir -p "$trashdir" && > + "$@" >"$trashdir/output" && > + test_line_count "$ops" "$val" "$trashdir/output" > +} > + > + > test_file_size () { Nit: one too many blank lines after the test body. A minor think-out-loud: I wonder if there would be value in deriving the name of the output file from the command being run (perhaps by using `tr` to translate oddball characters to underscore or to fold them out). This might or might not help someone debugging a test failure since there would be less chance of "$trashdir/output" being repeatedly clobbered. Anyhow, it's something that could be done later if deemed useful, not something for the present series. (I'm not interested in seeing this series re-rolled endlessly.)
Eric Sunshine <sunshine@sunshineco.com> writes: > A minor think-out-loud: I wonder if there would be value in deriving > the name of the output file from the command being run (perhaps by > using `tr` to translate oddball characters to underscore or to fold > them out). This might or might not help someone debugging a test > failure since there would be less chance of "$trashdir/output" being > repeatedly clobbered. Probably not. The iterations of output that are clobbered are all from the passing call to test_stdout_count_lines helper we made previously.
On 2021-07-06 12:24:05-0700, Junio C Hamano <gitster@pobox.com> wrote: > Eric Sunshine <sunshine@sunshineco.com> writes: > > > A minor think-out-loud: I wonder if there would be value in deriving > > the name of the output file from the command being run (perhaps by > > using `tr` to translate oddball characters to underscore or to fold > > them out). This might or might not help someone debugging a test > > failure since there would be less chance of "$trashdir/output" being > > repeatedly clobbered. > > Probably not. > > The iterations of output that are clobbered are all from the passing > call to test_stdout_count_lines helper we made previously. Yay, I also think it doesn't add much value. Since we're chaining command in a single test-case. I think most people with try to debug with "-i", which exits immediately. The only place it would help is debugging test failures with GitHub Actions, where developers could download artifarts for test failures from GitHub Actions.
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index f0448daa74..f9505be8fe 100644 --- a/t/test-lib-functions.sh +++ b/t/test-lib-functions.sh @@ -845,6 +845,32 @@ test_line_count () { fi } +# SYNOPSIS: +# test_stdout_line_count <bin-ops> <value> <cmd> [<args>...] +# +# test_stdout_line_count checks that the output of a command has the number +# of lines it ought to. For example: +# +# test_stdout_line_count = 3 git ls-files -u +# test_stdout_line_count -gt 10 ls +test_stdout_line_count () { + local ops val trashdir && + if test "$#" -le 3 + then + BUG "expect 3 or more arguments" + fi && + ops="$1" && + val="$2" && + shift 2 && + if ! trashdir="$(git rev-parse --git-dir)/trash"; then + BUG "expect to be run inside a worktree" + fi && + mkdir -p "$trashdir" && + "$@" >"$trashdir/output" && + test_line_count "$ops" "$val" "$trashdir/output" +} + + test_file_size () { test "$#" -ne 1 && BUG "1 param" test-tool path-utils file-size "$1"
In some tests, we're checking the number of lines in output of some commands, including but not limited to Git's command. We're doing the check by running those commands in the left side of a pipe, thus losing the exit status code of those commands. Meanwhile, we really want to check the exit status code of Git's command. Let's write the output of those commands to a temporary file, and use test_line_count separately in order to check exit status code of those commands properly. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> --- t/test-lib-functions.sh | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)