All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Jeff King" <peff@peff.net>
Subject: Re: [PATCH v4 7/7] t/README: Document the do's and don'ts of tests
Date: Tue, 06 Jul 2010 01:35:33 -0700 (PDT)	[thread overview]
Message-ID: <m3sk3xm2jr.fsf@localhost.localdomain> (raw)
In-Reply-To: <7vaaq58hhb.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > +Do:
> > +
> > + - Put as much code as possible inside test_expect_success and other
> > +   assertions.
> > +
> > +   Even code that isn't a test per se, but merely some setup code
> > +   should be inside a test assertion if at all possible. Test scripts
> > +   should only have trivial code outside of their assertions.
> 
> Let's make it even stronger; "should only have trivial" -> "shouldn't have
> any ... unless there is a good reason."

I think that the only thing that can and *should* be put outside
test_expect_* is creating helper file: test vectors ('expect' files),
configuration files, files that are to be arguments to commands, etc.
Is it covered by "there is a good reason"?  Isn't it too severe?

There probably should be description when to put creating such files
in test script, and when to put them as pre-made files in tXXXX/
subdirectory (non US-ASCII is one reason to put it as pre-made file).
 
-- 
Jakub Narebski
Poland
ShadeHawk on #git

  reply	other threads:[~2010-07-06  9:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-02 14:59 [PATCH v4 0/7] Improvements for t/README Ævar Arnfjörð Bjarmason
2010-07-02 14:59 ` [PATCH v4 1/7] t/README: The trash is in 't/trash directory.$name' Ævar Arnfjörð Bjarmason
2010-07-02 14:59 ` [PATCH v4 2/7] t/README: Typo: paralell -> parallel Ævar Arnfjörð Bjarmason
2010-07-02 14:59 ` [PATCH v4 3/7] t/README: Document the prereq functions, and 3-arg test_* Ævar Arnfjörð Bjarmason
2010-07-02 14:59 ` [PATCH v4 4/7] t/README: Document test_external* Ævar Arnfjörð Bjarmason
2010-07-02 14:59 ` [PATCH v4 5/7] t/README: Document test_expect_code Ævar Arnfjörð Bjarmason
2010-07-02 14:59 ` [PATCH v4 6/7] t/README: Add a section about skipping tests Ævar Arnfjörð Bjarmason
2010-07-02 14:59 ` [PATCH v4 7/7] t/README: Document the do's and don'ts of tests Ævar Arnfjörð Bjarmason
2010-07-06  2:35   ` Junio C Hamano
2010-07-06  8:35     ` Jakub Narebski [this message]
2010-07-06 13:02       ` Ævar Arnfjörð Bjarmason
2010-07-06 13:19         ` Jakub Narebski
2010-07-06 12:50     ` Ævar Arnfjörð Bjarmason

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=m3sk3xm2jr.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.