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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 1, 2010, 17:46 UTC
Message-ID: <AANLkTimUe39Z1Ce2NbfsJUyXe0-mY_CcmMmgk+kO_1a8@mail.gmail.com>
In-Reply-To: <AANLkTim1_Zfbrt4G_S2hj1zfF0VX-fM1AkwFyPp0B1qE@mail.gmail.com>

On Fri, Oct 1, 2010 at 17:39, Sverre Rabbelier <srabbelier@gmail.com> wrote:

Show 6 quoted lines

> Heya,
>
> On Fri, Oct 1, 2010 at 19:16, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> converted that code to use an external test similar no the TODO test I
>
> s/no/to/

Thanks, fixed.

Show 20 quoted lines

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