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

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

quoted

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