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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 7, 2010, 06:12 UTC
Message-ID: <20100907061213.GU1182@burratino>
In-Reply-To: <20100907055636.GA30357@sigill.intra.peff.net>

Jeff King wrote:

Show 18 quoted lines

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

Show 11 quoted lines

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