From: Johannes Sixt <j.sixt@viscovery.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brandon Casey <casey@nrlssc.navy.mil>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] t9301-fast-export: move unset of config variable into its own test function
Date: Fri, 22 Aug 2008 11:02:11 +0200 [thread overview]
Message-ID: <48AE8093.4070609@viscovery.net> (raw)
In-Reply-To: <7v7ia9bgqc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> 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
next prev parent reply other threads:[~2008-08-22 9:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-18 22:55 [FYI] How I compile on IRIX 6.5 with the MIPSpro compiler and ksh Brandon Casey
2008-08-18 23:02 ` [PATCH] Makefile: add section for SGI IRIX Brandon Casey
2008-08-18 23:05 ` [PATCH] git-compat-util.h: adjust for SGI IRIX 6.5 Brandon Casey
2008-08-18 23:09 ` [PATCH] unpack-trees.c: work around run-time array initialization flaw on " Brandon Casey
2008-08-18 23:14 ` [PATCH] templates/Makefile: work around SGI install which assumes / if ROOT not defined Brandon Casey
2008-08-18 23:37 ` Junio C Hamano
2008-08-19 0:52 ` Brandon Casey
2008-08-22 0:31 ` [PATCH] templates/Makefile: install is unnecessary, just use mkdir -p Brandon Casey
2008-08-18 23:16 ` [PATCH] test-lib.sh: work around ksh's trap shortcomings Brandon Casey
2008-08-18 23:48 ` Junio C Hamano
2008-08-19 0:06 ` Brandon Casey
2008-08-19 7:39 ` Junio C Hamano
2008-08-19 14:59 ` Brandon Casey
2008-08-19 1:27 ` Brandon Casey
2008-08-20 0:19 ` Brandon Casey
2008-08-20 11:36 ` Mike Ralphson
2008-08-18 23:17 ` [PATCH] t1002-read-tree-m-u-2way.sh: use 'git diff -U0' rather than 'diff -U0' Brandon Casey
2008-08-18 23:20 ` [PATCH] t9301-fast-export.sh: don't unset config variable while we're skipping test 4 Brandon Casey
2008-08-19 0:32 ` Junio C Hamano
2008-08-19 0:39 ` Brandon Casey
2008-08-22 0:48 ` [PATCH] t9301-fast-export: move unset of config variable into its own test function Brandon Casey
2008-08-22 8:18 ` Junio C Hamano
2008-08-22 8:23 ` Junio C Hamano
2008-08-22 9:02 ` Johannes Sixt [this message]
2008-08-22 21:11 ` Junio C Hamano
2008-08-18 23:51 ` [FYI] How I compile on IRIX 6.5 with the MIPSpro compiler and ksh Brandon Casey
2008-08-19 1:18 ` Boyd Lynn Gerber
2008-08-19 1:25 ` Brandon Casey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48AE8093.4070609@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=casey@nrlssc.navy.mil \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.