threads / patch / 13992

patchtest-lib.sh: add --long-tests option

Subject: [PATCH] test-lib.sh: add --long-tests option

## tl;dr

4 messages between Jun 17, 2008 and Jun 17, 2008. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Lea Wiemann· Jun 17, 2008, 01:29 UTC · lore

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(-)
Show changes to 2 files +6 −0

t/README, t/test-lib.sh

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
Junio C Hamano· Jun 17, 2008, 06:39 UTC · re: Lea Wiemann · lore

Re: [PATCH] test-lib.sh: add --long-tests option

Lea Wiemann <lewiemann@gmail.com> writes:
Show 13 quoted lines
> 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)
Hmm.

I am guessing that the reason why you do not unset GIT_TEST_LONG upfront in the script is because the user can do:

	$ cd t
        $ GIT_TEST_LONG=t; export GIT_TEST_LONG
        $ ./t9999-this-test.sh
        $ ./t9999-that-test.sh
or even:
	$ GIT_TEST_LONG=t make test

without having to say --long-tests from the command line that way. If that is the case, however, I wonder if this --long-tests option is even necessary.

Please do not get me wrong --- I am _not_ suggesting to unset (or set to empty) GIT_TEST_LONG at the beginning of test-lib before command line parsing. I do want the ability to run all the expensive tests with a single command line retained, as I expect it would be useful before a major release.

Lea Wiemann· Jun 17, 2008, 07:09 UTC · re: Junio C Hamano · lore

Re: [PATCH] test-lib.sh: add --long-tests option

Junio C Hamano wrote:
Show 10 quoted lines
> I am guessing that the reason why you do not unset GIT_TEST_LONG upfront
> in the script is because the user can do:
> 
>         $ GIT_TEST_LONG=t; export GIT_TEST_LONG
>         $ ./t9999-this-test.sh
>         $ ./t9999-that-test.sh
> 
> or even:
> 
> 	$ GIT_TEST_LONG=t make test
Yes, that's the idea.
> If that is the case, however, I wonder if this --long-tests option is even
> necessary.

It's very convenient for development, where you go back and forth between "./t9503-gitweb-Mechanize.sh -v -l" and "./t9503-gitweb-Mechanize.sh -v". All it takes is to add or remove the "-l" at each invocation. So I think the switch is actually quite useful.

-- Lea
Junio C Hamano· Jun 17, 2008, 07:15 UTC · re: Lea Wiemann · lore

Re: [PATCH] test-lib.sh: add --long-tests option

Lea Wiemann <lewiemann@gmail.com> writes:
Show 22 quoted lines
> Junio C Hamano wrote:
>> I am guessing that the reason why you do not unset GIT_TEST_LONG upfront
>> in the script is because the user can do:
>>
>>         $ GIT_TEST_LONG=t; export GIT_TEST_LONG
>>         $ ./t9999-this-test.sh
>>         $ ./t9999-that-test.sh
>>
>> or even:
>>
>> 	$ GIT_TEST_LONG=t make test
>
> Yes, that's the idea.
>
>> If that is the case, however, I wonder if this --long-tests option is even
>> necessary.
>
> It's very convenient for development, where you go back and forth
> between "./t9503-gitweb-Mechanize.sh -v -l" and
> "./t9503-gitweb-Mechanize.sh -v".  All it takes is to add or remove
> the "-l" at each invocation.  So I think the switch is actually quite
> useful.

Heh, one-shot export "GIT_TEST_LONG_t ./t9999-this-test.sh" would equally be swift, but Ok.

← back to recent threads