Junio C Hamano <gitster@xxxxxxxxx> writes:
> "Hariom Verma via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
>> @@ t/t6300-for-each-ref.sh: test_expect_success '%(trailers:only) and %(trailers:un
>> + option="$2"
>> + expect="$3"
>> + test_expect_success "$title" '
>> -+ echo $expect >expect &&
>> ++ printf "$expect\n" >expect &&
>
> Are we sure that "$expect" would not ever have any '%' in it, to
> confuse printf?
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@xxxxxxxxxxx>'
test_trailer_option 'expect two lines' \
'trailers:key=Reviewed-by' \
'Reviewed-by: A U Thor <author@xxxxxxxxxxx>' \
'Reviewed-by: R E Viewer <reviewer@xxxxxxxxxxx>'
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@xxxxxxxxxxx>
Reviewed-by: R E Viewer <reviewer@xxxxxxxxxxx>
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@xxxxxxxxxxx>
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.
