Re: [PATCH v3 0/3] Unify trailers formatting logic for pretty.c and ref-filter.c

Junio C Hamano <gitster@pobox.com> writes:

Just to make sure we won't waste your time in useless roundtrip(s), let me say that possible unacceptable answers are:

 - no, right now nobody passes a % in it
 - no, I do not expect anybody needs to pass a % in it
 - when somebody really needs to pass a %, they can write it as %%

The last one is the worst one, by the way.

The point of adding a test_trailer_option HELPER function is to HELP the developers who write tests, now and in the future. There are some things they MUST know to use the helper successfully, like it takes three parameters, the first one being the test title, the second one is the string you'd give as the "--format=<format>" option to the for-each-ref command, and the third one is the expected output.

Forcing them to know any more than that is *not* helping them.

The shell programming language is perfectly capable of passing an argument that happens to be a multi-line string to functions and external commands, and the developers who are writing test knows that already (the last argument to test_expect_success used everywhere in the test suite, that is a multi-line code snippet, is a good example). When they need to write an expected output that is two lines, they expect to be able to write things like

	test_trailer_option title format-string \
	'expected line #1
	expected line #2'

without having to worry about the need for special formatting that is applicable *only* when passing argument to this helper. They do not need to know that they cannot pass backslash-en literally, and have to say '\\n' instead, or they have to double a per-cent sign, only when using this helper but not other helper functions.

In the message I am replying to, I used

	printf "%s\n" "$expect"

for a reason. We expect that trailer options output are complete lines, so it is annoying to force the caller to write the final newline, especially if many of the callers have only one line of expected output. So

    test_trailer_option title format-string 'expected output'

would end up doing

	printf "%s\n" "expected output" >expect

to write a complete line, i.e. a caller does not have to say any of

    test_trailer_option title format-string 'expected output\n'

    test_trailer_option title format-string 'expected output
    '

    lf='
    '
    test_trailer_option title format-string "expected output$lf"

If we do not need to extend test_trailer_option with further "features" (like "check output case insensitively this time" or "allow output lines in any order"), we can make it even nicer and easier to use for callers, by the way.

For example, with this (by the way, make sure there are SP on both sides around "()", that's our house style):

	test_trailer_option () {
		title=$1 option=$2
		shift 2
		if test $# != 0
		then
			printf "%s\n" "$@"
		fi >expect
		test_expect_success "$title" '
			... >actual &&
			test_cmp expect actual &&
			... >actual &&
			test_cmp expect actual
		'
	}

the caller can do

	test_trailer_option 'single line output' \
		'trailers:key=Signed-off-by' \
		'Signed-off-by: A U Thor <author@example.com>'

	test_trailer_option 'expect two lines' \
		'trailers:key=Reviewed-by' \
		'Reviewed-by: A U Thor <author@example.com>' \
		'Reviewed-by: R E Viewer <reviewer@example.com>'

	test_trailer_option 'no output expected' 'trailers:key=no-such:' ''

That is, instead of "the first arg is title, the second is format and the third is the entire expected output", the helper's manual can say "give title and format as the first and the second argument. Each argument after that is an expected output, one line per arg."

Another possibility is to feed the expected output from the standard input of the helper, e.g.

	test_trailer_option () {
		title=$1 option=$2
		cat >expect
		test_expect_success "$title" '
			... >actual &&
			test_cmp expect actual &&
			... >actual &&
			test_cmp expect actual
		'
	}

And the caller can now do:

	test_trailer_option 'expect two lines' 'trailers:key=Reviewed-by' <<-\EOF
        Reviewed-by: A U Thor <author@example.com>
        Reviewed-by: R E Viewer <reviewer@example.com>
	EOF

It is a bit cumbersome when the expected output is a single line:

	test_trailer_option 'single line output' 'trailers:key=Signed-off-by' <<-\EOF
	Signed-off-by: A U Thor <author@example.com>
	EOF

but the contrast between the "two-line expected" case and this one would be easy to see when reading the tests. The pattern to write "expect no output" would be quite simple, too:

	test_trailer_option 'no output expected' 'trailers:key=no-such:' </dev/null

Among the ones designed while writing this response, I would think I like the last one, i.e. "the first arg is title, the second arg is format, and the expected output is given from the standasd output" probably the best.

Thanks.