git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lea Wiemann <lewiemann@gmail.com>
To: git@vger.kernel.org
Cc: Lea Wiemann <LeWiemann@gmail.com>
Subject: [PATCH] test-lib.sh: add --long-tests option
Date: Tue, 17 Jun 2008 03:29:02 +0200	[thread overview]
Message-ID: <1213666142-24680-1-git-send-email-LeWiemann@gmail.com> (raw)

Add a --long-tests option to test-lib.sh, which enables tests to
selectively run more exhaustive (longer running, potentially
brute-force) tests.  Such exhaustive tests would only be useful if one
works on the specific module that is being tested -- for a general "cd
t/; make" to check whether everything is OK, such exhaustive tests
shouldn't be run by default since the longer it takes to run the
tests, the less often they are actually run.

Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
---
Right now I'm using this in the Mechanize test for exhaustive link
checking on each page.  I've caught bugs with this (such as the
"[PATCH] gitweb: fix support for repository directories with spaces"
that I just sent), so it's actually useful for development, but it's
so slow that I wouldn't want it to be run unless the user requests it
-- the link checking is really quite brute-force and doesn't cover
much more than the actual test.  Actual breakages (regressions) are
quite likely to be caught by the normal test.

Running the Mechanize test in long mode takes more than 1 minute on my
system, vs 5 seconds in normal mode -- and that's just with a really
short draft of the test suite.  So running those long tests
unconditionally would slow down "cd t; make" unncessarily, and we want
tests to be fast so that people actually run them.


Is the wording OK?  --long-tests and GIT_TEST_LONG were the best terms
I could come up with off the top of my head.


(ISTR that there's some large open source project that uses this
strategy (long vs. normal tests) quite extensively, but I can't recall
which one; hints appreciated.  GCC uses it in its compatibility tests;
its testsuite/README.compat reads,

  Normally, only a small amount of compatibility tests is run.
  Setting RUN_ALL_COMPAT_TESTS=1 in the environment before running the
  testsuite enables running all compatibility tests, but might take
  significantly longer than it takes without this variable.)

-- Lea

 t/README      |    4 ++++
 t/test-lib.sh |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/t/README b/t/README
index 70841a4..dc89263 100644
--- a/t/README
+++ b/t/README
@@ -54,6 +54,10 @@ You can pass --verbose (or -v), --debug (or -d), and --immediate
 	This causes the test to immediately exit upon the first
 	failed test.
 
+--long-tests::
+	This causes additional long-running tests to be run (where
+	available), for more exhaustive testing.
+
 
 Naming Tests
 ------------
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 163167c..4cd99af 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -80,6 +80,8 @@ do
 		debug=t; shift ;;
 	-i|--i|--im|--imm|--imme|--immed|--immedi|--immedia|--immediat|--immediate)
 		immediate=t; shift ;;
+	-l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
+		export GIT_TEST_LONG=t; shift ;;
 	-h|--h|--he|--hel|--help)
 		help=t; shift ;;
 	-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
-- 
1.5.6.rc3.7.ged9620

             reply	other threads:[~2008-06-17  6:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-17  1:29 Lea Wiemann [this message]
2008-06-17  6:39 ` [PATCH] test-lib.sh: add --long-tests option Junio C Hamano
2008-06-17  7:09   ` Lea Wiemann
2008-06-17  7:15     ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2008-06-17  6:26 Lea Wiemann

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=1213666142-24680-1-git-send-email-LeWiemann@gmail.com \
    --to=lewiemann@gmail.com \
    --cc=git@vger.kernel.org \
    /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).