Re: [PATCH 3/6] test-lib: verbose mode for only tests matching a pattern
On Wed, May 29, 2013 at 01:00:00AM -0400, Jeff King wrote:
Show 5 quoted lines
> So we see 83 and 84 non-verbose, which is good. And we see the actual
> output from 85 (the output from a "git checkout"). But we do not see the
> "expecting success" for it. We see it for the _next_ test, which we
> should not see at all. So I think your toggling is happening in the
> wrong spot, but I haven't looked further than that.
I think you want something more like:
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 5251009..75351f5 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -349,6 +349,7 @@ test_expect_failure () {
export test_prereq
if ! test_skip "$@"
then
+ toggle_verbose
say >&3 "checking known breakage: $2"
if test_run_ "$2" expecting_failure
then
@@ -367,6 +368,7 @@ test_expect_success () {
export test_prereq
if ! test_skip "$@"
then
+ toggle_verbose
say >&3 "expecting success: $2"
if test_run_ "$2"
then
diff --git a/t/test-lib.sh b/t/test-lib.sh
index b4e81bc..165e84e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -400,7 +400,6 @@ setup_test_eval () {
setup_test_eval () {
setup_malloc_check
toggle_valgrind
- toggle_verbose
}
teardown_test_eval () {
teardown_malloc_check
However, I'm not sure the toggle is the right thing. However, the whole
toggle thing seems weird to me, as there is a big "gap" between
finishing test X and starting test X+1 where we inherit the verbosity
(and valgrind) settings from X. In general we frown upon doing much at
all outside of test_expect_*, but I would think that:
test_expect_success 'one' '...'
git foo
test_expect_success 'two' '...'
when run with "--valgrind-only=1" would not run the intermediate "git
foo" with valgrind. I would have expected the implementation to be more
like:
maybe_turn_on_valgrind
maybe_turn_on_verbose
run_the_actual_test
maybe_turn_off_verbose
maybe_turn_off_valgrind
rather than relying on the next test to return to normal. I doubt that
it matters too much in practice, though.
-Peff
Jeff King <peff@peff.net>