Re: [PATCH] test-lib: make test_expect_code a test command

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

 



On Fri, Oct 1, 2010 at 17:39, Sverre Rabbelier <srabbelier@xxxxxxxxx> wrote:
> Heya,
>
> On Fri, Oct 1, 2010 at 19:16, Ãvar ArnfjÃrà Bjarmason <avarab@xxxxxxxxx> wrote:
>> converted that code to use an external test similar no the TODO test I
>
> s/no/to/

Thanks, fixed.

>> +cat >expect <<EOF &&
>> +not ok - 1 tests clean up even after a failure
>> +#
>> +# Â Â Â Â Âtouch clean-after-failure &&
>> +# Â Â Â Â Âtest_when_finished rm clean-after-failure &&
>> +# Â Â Â Â Â(exit 1)
>> +#
>> +not ok - 2 failure to clean up causes the test to fail
>> +#
>> +# Â Â Â Â Âtest_when_finished \"(exit 2)\"
>> +#
>> +# failed 2 among 2 test(s)
>> +1..2
>> +EOF
>> + Â Âtest_cmp expect out)
>
> I still like the putting-the-code-in-a-separate-harness, but I'm
> wondering if we can't come up with something better than comparing
> with test output that could change in the future... unless we decide
> to standardize on TAP and not deviate from it?

Since t0000-basic.sh is the sanity test for the test-lib.sh itself
having at least some comparison of output is a good thing. It's a nice
sanity check in case something ends up changing it.

It's easy to change it if we change the output, but at least we'll be
testing for it explicitly.

> Either case, wouldn't it at least be a good idea to get rid of the
> parts after the # in the comparrison?

I thought it was simplest to just compare the complete output.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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