Re: [PATCH 08/16] t5304: use helper to report failure of "test foo = bar"

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2014, 22:17 UTC
Message-ID: <xmqqsij4kdch.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141003202743.GH16293@peff.net>

Jeff King <peff@peff.net> writes:

Show 15 quoted lines

> For small outputs, we sometimes use:
>
>   test "$(some_cmd)" = "something we expect"
>
> instead of a full test_cmp. The downside of this is that
> when it fails, there is no output at all from the script.
> Let's introduce a small helper to make tests easier to
> debug.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This is in the same boat as the last commit; we can drop it without
> hurting the rest of the series.
>
> Is test_eq too cutesy or obfuscated?

Not really. As long as its two strings are not tooooo long, the output may still be readable.

Show 9 quoted lines

> I have often wanted it when
> debugging other tests, too. Our usual technique is to do:
>
>   echo whatever >expect &&
>   do_something >actual &&
>   test_cmp expect actual
>
> That's a bit verbose. We could hide it behind something like test_eq,
> too, but it introduces several extra new processes.

What do you mean by "extra new processes"? Whether open coded in a verbose way, or wrapped inside a helper, e.g.

	test_eql () {
		echo "$1" >expect &&
                shift &&
                "$@" >actual &&
                test_cmp expect actual
	}
        ...
	test_eql whatever do_something

the number of processes would be the same, no?

Or do you mean test_cmp is an extra process compared with

	test_eq whatever "$(do_something)"

Hopefully, do_something does something more than what takes test_cmp to run, so I wouldn't be worried too much about it.