Jeff King <peff@xxxxxxxx> writes:
> 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@xxxxxxxx>
> ---
> 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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html