Re: [PATCH] t9301-fast-export: move unset of config variable into its own test function

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Aug 22, 2008, 09:02 UTC
Message-ID: <48AE8093.4070609@viscovery.net>
In-Reply-To: <7v7ia9bgqc.fsf@gitster.siamese.dyndns.org>

Junio C Hamano schrieb:

Show 19 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
>> For this particular case, what we are interested in testing is not that
>> "config --unset" exits with 0 status.  We are however interested in making
>> sure that i18n.commitencoding is not set when the body of #12 runs.
>>
>> So I think a more appropriate change would be something like this for this
>> particular case.
> 
> Having said that, we may want to have an easier way to exclude certain
> classes of pieces, and also encourage test writers to group pieces that
> are related to these classes together.
> 
> For example, this introduces a new environment you can set,
> GIT_SKIP_TEST_CLASS, which is a space separated list of classes of
> features that you would want to exclude from the test.
> test_expect_success/failure can now take an optional "class token" as the
> first parameter (they traditionally took only two parameters, but with
> class token, they take three).

Nice idea. Another class would be the tests that depend on that the filesystem supports symbolic links.

> -test_expect_success 'iso-8859-1' '
> +test_expect_success I18N 'iso-8859-1' '

How do the tests look like if this token is the *last* argument?

To continue the idea, please look into t5302-pack-index.sh: We skip some tests if we don't have support for 64bit file offsets. Making these tests a "static" class would not be appropriate because the condition whether 64bit support is present is derived dynamically by the testsuite. What if we could write tests like this:

test_expect_success \
    'index v2: verify a pack with some 64-bit offsets' \
    'git verify-pack -v "test-3-${pack3}.pack"' \
    'test "$have_64bits"'

i.e. the 3rd argument is a condition that tells whether the test should be run. And in other cases the 3rd argument is the token that you propose:

test_expect_success 'iso-8859-1' '

     ...test goes here...

' I18N

Hm?

-- Hannes