Re: [PATCH 3/3] t: detect and signal failure within loop

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> "Eric Sunshine via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
>> diff --git a/t/t5329-pack-objects-cruft.sh b/t/t5329-pack-objects-cruft.sh
>> index 8968f7a08d8..6049e2c1d78 100755
>> --- a/t/t5329-pack-objects-cruft.sh
>> +++ b/t/t5329-pack-objects-cruft.sh
>> @@ -29,7 +29,7 @@ basic_cruft_pack_tests () {
>>  				while read oid
>>  				do
>>  					path="$objdir/$(test_oid_to_path "$oid")" &&
>> -					printf "%s %d\n" "$oid" "$(test-tool chmtime --get "$path")"
>> +					printf "%s %d\n" "$oid" "$(test-tool chmtime --get "$path")" || exit 1
>>  				done |
>>  				sort -k1
>>  			) >expect &&
>
> With the loop being on the upstream of a pipe, does the added "exit
> 1" have any effect?

And the answer is "no".  Without use of rhetorical question:

    The loop is on the upstream side of a pipe, so "exit 1" will be
    lost.  "sort -k1" will get a shortened output, unless the
    failure happens at the last iteration, so it is likely that the
    test may fail, but relying on the "expect" (what is supposed to
    have the _right_ answer) file not being right to get our
    breakage noticed does not sound right.

> Everything else in these three patches looked very sensible, but
> this one I found questionable.

As to the questionable one, we could probably do something like the
attached patch if we really wanted to.  We can guarantee that this
"expect" will never match any "actual", which is output from
pack-mtimes test tool command.  Whatever "tricky/ugly" approach we
choose to take, I think this one deserves to be done in a single
patch on its own with an explanation.

----- >8 --------- >8 --------- >8 --------- >8 ----
t5329: notice a failure within a loop

We try to write "|| return 1" at the end of a sequence of &&-chained
command in a loop of our tests, so that a failure of any step during
the earlier iteration of the loop can properly be caught.

There is one loop in this test script that is used to compute the
expected result, that will be later compared with an actual output
produced by the "test-tool pack-mtimes" command.  This particular
loop, however, is placed on the upstream side of a pipe, whose
non-zero exit code does not get noticed.

Emit a line that will never be produced by the "test-tool pack-mtimes"
to cause the later comparison to fail.  As we use test_cmp to compare
this "expected output" file with the "actual output", the "error
message" we are emitting into the expected output stream will stand
out and shown to the tester.

Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
 t/t5329-pack-objects-cruft.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git c/t/t5329-pack-objects-cruft.sh w/t/t5329-pack-objects-cruft.sh
index 6049e2c1d7..43d752acc7 100755
--- c/t/t5329-pack-objects-cruft.sh
+++ w/t/t5329-pack-objects-cruft.sh
@@ -29,7 +29,8 @@ basic_cruft_pack_tests () {
 				while read oid
 				do
 					path="$objdir/$(test_oid_to_path "$oid")" &&
-					printf "%s %d\n" "$oid" "$(test-tool chmtime --get "$path")"
+					printf "%s %d\n" "$oid" "$(test-tool chmtime --get "$path")" ||
+					echo "object list generation failed for $obj"
 				done |
 				sort -k1
 			) >expect &&




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux