Re: [PATCH v5 1/3] test-lib-functions: introduce test_stdout_line_count

[Eric Sunshine <sunshine@sunshineco.com>]

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.)