Re: [PATCH 3/6] test-lib: verbose mode for only tests matching a pattern
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 29, 2013, 17:53 UTC
- Message-ID
- <7vmwrdu0z5.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130529050732.GC31762@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 64 quoted lines
> On Wed, May 29, 2013 at 01:00:00AM -0400, Jeff King wrote:
>
>> 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.That matches my expectation as well (I had the same thought while reading the series).
Thanks.