Re: [PATCH 2/3] t0000: simplify HARNESS_ACTIVE hack

2013-12-28 Thread Jonathan Nieder
Jeff King wrote:

> --- a/t/t-basic.sh
> +++ b/t/t-basic.sh
> @@ -50,11 +50,11 @@ run_sub_test_lib_test () {
>   shift 2
>   mkdir "$name" &&
>   (
> - # Pretend we're a test harness.  This prevents
> - # test-lib from writing the counts to a file that will
> - # later be summarized, showing spurious "failed" tests
> - HARNESS_ACTIVE=t &&
> - export HARNESS_ACTIVE &&
> + # Pretend we're not running under a test harness, whether we
> + # are or not. The test-lib output depends on the setting of
> + # this variable, so we need a stable setting under which to run
> + # the sub-test.
> + sane_unset HARNESS_ACTIVE &&

Makes sense.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/3] t0000: simplify HARNESS_ACTIVE hack

2013-12-28 Thread Jeff King
Commit 517cd55 set HARNESS_ACTIVE unconditionally in
sub-tests, because that value affects the output of
"--verbose". t needs stable output from its sub-tests,
and we may or may not be running under a TAP harness.

That commit made the decision to always set the variable,
since it has another useful side effect, which is
suppressing writes to t/test-results by the sub-tests (which
would just pollute the real results).

Since the last commit, though, the sub-tests have their own
test-results directories, so this is no longer an issue. We
can now update a few comments that are no longer accurate
nor necessary.

We can also revisit the choice of HARNESS_ACTIVE. Since we
must choose one value for stability, it's probably saner to
have it off. This means that future patches could test
things like the test-results writing, or the "--quiet"
option, which is currently ignored when run under a harness.

Signed-off-by: Jeff King 
---
I do not have any plans to write such tests, and I'd be OK if we wanted
to stop this just at fixing up the comments. But it took me a while to
figure out what is going on, and I believe unsetting HARNESS_ACTIVE in
the sub-tests is the choice that is least likely to cause somebody in
the future to have to re-figure it out. :)

 t/t-basic.sh | 14 +-
 t/test-lib.sh|  2 --
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/t/t-basic.sh b/t/t-basic.sh
index bc4e3e2..e6c5b63 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -50,11 +50,11 @@ run_sub_test_lib_test () {
shift 2
mkdir "$name" &&
(
-   # Pretend we're a test harness.  This prevents
-   # test-lib from writing the counts to a file that will
-   # later be summarized, showing spurious "failed" tests
-   HARNESS_ACTIVE=t &&
-   export HARNESS_ACTIVE &&
+   # Pretend we're not running under a test harness, whether we
+   # are or not. The test-lib output depends on the setting of
+   # this variable, so we need a stable setting under which to run
+   # the sub-test.
+   sane_unset HARNESS_ACTIVE &&
cd "$name" &&
cat >"$name.sh" <<-EOF &&
#!$SHELL_PATH
@@ -235,16 +235,13 @@ test_expect_success 'test --verbose' '
grep -v "^Initialized empty" test-verbose/out+ >test-verbose/out &&
check_sub_test_lib_test test-verbose <<-\EOF
> expecting success: true
-   > Z
> ok 1 - passing test
> Z
> expecting success: echo foo
> foo
-   > Z
> ok 2 - test with output
> Z
> expecting success: false
-   > Z
> not ok 3 - failing test
> # false
> Z
@@ -267,7 +264,6 @@ test_expect_success 'test --verbose-only' '
> Z
> expecting success: echo foo
> foo
-   > Z
> ok 2 - test with output
> Z
> not ok 3 - failing test
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 1cf78d5..1531c24 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -481,8 +481,6 @@ test_at_end_hook_ () {
 test_done () {
GIT_EXIT_OK=t
 
-   # Note: t relies on $HARNESS_ACTIVE disabling the .counts
-   # output file
if test -z "$HARNESS_ACTIVE"
then
test_results_dir="$TEST_OUTPUT_DIRECTORY/test-results"
-- 
1.8.5.1.399.g900e7cd

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html