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

Junio C Hamano schrieb:

Junio C Hamano [off-list ref] writes:

quoted

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