Junio C Hamano schrieb:
> Junio C Hamano <gitster@xxxxxxxxx> 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
--
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
