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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).