From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>,
"GIT Mailing-list" <git@vger.kernel.org>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [RFC/PATCH] t3300-*.sh: Fix a TAP parse error
Date: Sun, 19 Aug 2012 18:57:37 +0100 [thread overview]
Message-ID: <50312911.30904@ramsay1.demon.co.uk> (raw)
In-Reply-To: <7vk3wyxv6e.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Ramsay Jones wrote:
>>> Junio C Hamano wrote:
>>
>>>> Observing that all well-written test scripts we have begin with this
>>>> boilerplate line:
>>>>
>>>> test_expect_success setup '
>>>>
>>>> I wouldn't mind introducing a new helper function test_setup that
>>>> behaves like test_expect_success but is meant to be used in the
>>>> first "set-up" phase of the tests in a test script.
>>
>> Neat. This could be used for later set-up tests, too, perhaps with a
>> long-term goal of making non set-up tests independent of each other
>> (reorderable and skippable).
>>
>> [...]
>>> [1] For example, what should/will happen if someone uses test_must_fail,
>>> test_might_fail, etc., within the test_fixture script? Should they simply
>>> be banned within a text_fixture?
>>
>> Why wouldn't they act just like they do in test_expect_success blocks?
>>
>> FWIW I find Junio's test_setup name more self-explanatory. What
>> mnemonic should I be using to remember the _fixture name?
>
> I see that I was distracted by the "where does the fixture come
> from" and did not follow through.
>
> I think what it does makes sense (I haven't checked all the
> redirections, though). Do we want to resurrect the topic? It needs
> a paragraph in the proposed commit log and t/README to explain the
> motivation and the usage.
Yes, this is on my TODO list.
I will name the function 'test_setup' rather than 'test_fixture'.
Also, the test_fixture function had a single script parameter, since
I didn't see the point of having a "title" like test_expect_success.
However, I'm now in two minds about this; if it were to take a title
it may be useful to include the title in the error message, if the
test contained multiple calls to test_setup. I'm still inclined to
*not* include a title parameter ...
ATB,
Ramsay Jones
prev parent reply other threads:[~2012-08-19 19:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-21 17:46 [RFC/PATCH] t3300-*.sh: Fix a TAP parse error Ramsay Jones
2012-07-21 18:20 ` Jonathan Nieder
2012-07-24 18:34 ` Ramsay Jones
2012-07-24 19:21 ` Jonathan Nieder
2012-07-25 18:36 ` Ramsay Jones
2012-07-24 19:57 ` Junio C Hamano
2012-07-25 19:07 ` Ramsay Jones
2012-07-25 20:51 ` Jonathan Nieder
2012-07-25 22:08 ` Junio C Hamano
2012-07-28 18:12 ` Ramsay Jones
2012-07-28 18:03 ` Ramsay Jones
2012-08-16 23:40 ` Junio C Hamano
2012-08-19 17:57 ` Ramsay Jones [this message]
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=50312911.30904@ramsay1.demon.co.uk \
--to=ramsay@ramsay1.demon.co.uk \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.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.