git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 25 Jul 2012 20:07:05 +0100	[thread overview]
Message-ID: <501043D9.70604@ramsay1.demon.co.uk> (raw)
In-Reply-To: <7veho1exu6.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
[...]
> As I am more worried about longer-term health of the codebase, what
> the part you moved outside test_expect_* with this patch happens to
> do _right now_ is of secondary importance, at least from my point of
> view.  The next patch that updates this scirpt may want to run more
> involved commands that can fail in different ways.
> 
> Being able to rely on the protection test_expect_* gives us in the
> set-up phase of the test has been very valuable (in addition to
> making the result more readable) to us.  Can we keep that property
> in some way while also keeping the ability to skip the remainder of
> the test script?
> 
> 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. Perhaps we can
> give its failure a meaning different than failures in other normal
> tests (e.g. "even set-up fails, and the remainder of the test is N/A
> here, hence abort the whole thing"), and do not count "test_setup"
> as part of the test (i.e. do not increment $test_count and friends).

Heh, I did exactly this (except mine was called test_fixture) as part
of my first (abandoned) attempt to address this problem. :-D

I've attached the patch below, just for discussion.

I didn't test it very much, but it seems to work with a superficial
workout:

    $ cd t
    $ ./t3300-funny-names.sh
    # passed all 0 test(s)
    1..0 # SKIP Your filesystem does not allow tabs in filenames
    $

    $ ./t3300-funny-names.sh -v
    Initialized empty Git repository in /home/ramsay/git/t/trash directory.t3300-fun
    ny-names/.git/
    test fixture:
            cat >"$p0" <<-\EOF &&
            1. A quick brown fox jumps over the lazy cat, oops dog.
            2. A quick brown fox jumps over the lazy cat, oops dog.
            3. A quick brown fox jumps over the lazy cat, oops dog.
            EOF

            { cat "$p0" >"$p1" || :; } &&
            { echo "Foo Bar Baz" >"$p2" || :; } &&

            if test -f "$p1" && cmp "$p0" "$p1"
            then
                    test_set_prereq TABS_IN_FILENAMES
            fi

    ./test-lib.sh: line 274: tabs   ," (dq) and spaces: No such file or directory

    # passed all 0 test(s)
    1..0 # SKIP Your filesystem does not allow tabs in filenames
    $

    $ prove --exec sh t3300-funny-names.sh
    t3300-funny-names.sh .. skipped: Your filesystem does not allow tabs in filename
    s
    Files=1, Tests=0,  1 wallclock secs ( 0.03 usr  0.05 sys +  0.87 cusr  0.41 csys
     =  1.36 CPU)
    Result: NOTESTS
    $

So why did I abandon this patch? Well, I didn't really; I just decided
that I needed *much* more time to polish[1] 'test_fixture'. I wanted to
fix the "TAP parse error" problem before v1.7.12-rc0! :(

HTH

ATB,
Ramsay Jones

[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?

--- >8 ---
Subject: [PATCH] test-lib-functions.sh: Add a test_fixture function


Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
 t/t3300-funny-names.sh  |  2 +-
 t/test-lib-functions.sh | 11 +++++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/t/t3300-funny-names.sh b/t/t3300-funny-names.sh
index 1f35e55..59331a0 100755
--- a/t/t3300-funny-names.sh
+++ b/t/t3300-funny-names.sh
@@ -15,7 +15,7 @@ p0='no-funny'
 p1='tabs	," (dq) and spaces'
 p2='just space'
 
-test_expect_success 'setup' '
+test_fixture '
 	cat >"$p0" <<-\EOF &&
 	1. A quick brown fox jumps over the lazy cat, oops dog.
 	2. A quick brown fox jumps over the lazy cat, oops dog.
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 80daaca..b70c963 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -302,6 +302,17 @@ test_expect_success () {
 	echo >&3 ""
 }
 
+test_fixture () {
+	test "$#" = 1 ||
+	error "bug in test script: must be single argument to test_fixture"
+	say >&3 "test fixture: $1"
+	if ! test_run_ "$1"
+	then
+		error "failure in test_fixture code"
+	fi
+	echo >&3 ""
+}
+
 # test_external runs external test scripts that provide continuous
 # test output about their progress, and succeeds/fails on
 # zero/non-zero exit code.  It outputs the test output on stdout even
-- 
1.7.11.2

  reply	other threads:[~2012-07-25 19:49 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 [this message]
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

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=501043D9.70604@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 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).