Re: guarding everything with test_expect_success (Re: [PATCH 6/7] t1303 (config): style tweaks)

[Jonathan Nieder <jrnieder@gmail.com>]

Jeff King wrote:

> Perhaps we could refactor it into a
> set of two functions that keep state? E.g., something like:
> 
> test_start 'setup'
> cat >expect <<EOF
> ... whatever ...
> EOF
> test_end success
> 
> test_start 'description'
> git frob >actual &&
> test_cmp expect actual
> test_end success
> 
> where test_start would set up >&3 and >&4 as usual, and test_end would
> check $? and report the status. The biggest problem I see is that we
> never have the actual shell script snippet as a string, so we don't have
> a way of printing it for "-v" (or on failure). Hmm.

FWIW I don't mind this idea (to be used as an alternative to
test_expect_success when quoting issues get ugly).  Maybe the harness
could fetch the snippet by parsing $0?  (Sorry, couldn't resist.
Something simpler might be possible: e.g., a special

test_expect_success 'description' - <<\test_end
cat >expect <<EOF
... whatever ...
EOF
test_end

syntax.)

>> I don't know: I think
>> 
>> 	cat >expect <<-\EOF &&
>> 	...
>> 	EOF
>> 
>> is pretty readable.  The problem with sticking to
>
> Yeah, I almost mentioned that, but for some reason in the back of my
> mind <<- is not actually portable. Perhaps I am just thinking of the
> fact that perl does not support it.

I seem to remember some language where the here documents would snip
some well determined constant amount of whitespace from the enclosed
lines.  Unfortunately in the shell, that is not the rule: <<- just
trims out all the leading tabs.

So when expected output includes leading tabs, it is ugly again.

	q_to_tab <<-\EOF
	Like this:

	Q1. indented line
	Q2. second indented line
	EOF