All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>,
	Paul Tan <pyokagan@gmail.com>,
	git@vger.kernel.org, Stefan Beller <sbeller@google.com>,
	David Aguilar <davvid@gmail.com>
Subject: Re: sh -x -i -v with continuous integration, was Re: [PATCH 1/4] t7601: test for pull.ff=true overrides merge.ff=false
Date: Sat, 16 May 2015 11:28:58 -0400	[thread overview]
Message-ID: <20150516152858.GA19269@peff.net> (raw)
In-Reply-To: <xmqqh9rf84we.fsf@gitster.dls.corp.google.com>

On Thu, May 14, 2015 at 10:06:57AM -0700, Junio C Hamano wrote:

> And I would say that "verbose test" is not a useful way to make the
> test output more verbose for Human's sake; GIT_TEST_OPTS="-v -x -i"
> on the other hand is.
> 
> I am very tempted to suggest doing this ;-)
> 
>  t/test-lib-functions.sh | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 0698ce7..c6c67e8 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -638,8 +638,14 @@ test_cmp_bin() {
>  }
>  
>  # Call any command "$@" but be more verbose about its
> -# failure. This is handy for commands like "test" which do
> -# not output anything when they fail.
> +# failure. This may seem handy for commands like "test" which do
> +# not output anything when they fail, but in practice not
> +# very useful for things like 'test "$actual" = "$expect"',
> +# as this only shows the actual values (i.e. after $actual and
> +# $expect are turned into the values in these variables).
> +#
> +# In short, do not add use of this; this is kept only to
> +# avoid having to remove its use (for now).

Sorry, but I completely disagree here (no surprise, as I was the one who
added "verbose").

It's true that it does not tell you the original commands that were
handed to the shell. But neither does the output of "test_cmp". However,
combined with the output of the test code snippet that we already
provide, it is often clear.

E.g., let's "break" a verbose test from the test suite and break it:

diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1b2e981..f3206a3 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -113,7 +113,7 @@ test_expect_success 'diff-filter=M' '
 
 	actual=$(git log --pretty="format:%s" --diff-filter=M HEAD) &&
 	expect=$(echo second) &&
-	verbose test "$actual" = "$expect"
+	verbose test "$actual" = "foo-$expect"
 
 '
 

Right now the output is:

    expecting success: 
    
            actual=$(git log --pretty="format:%s" --diff-filter=M HEAD) &&
            expect=$(echo second) &&
            verbose test "$actual" = "foo-$expect"
    
    
    command failed:  'test' 'second' '=' 'foo-second'
    not ok 10 - diff-filter=M

which IMHO is pretty helpful. If we take away the "verbose", we get:

    expecting success: 
    
            actual=$(git log --pretty="format:%s" --diff-filter=M HEAD) &&
            expect=$(echo second) &&
            test "$actual" = "foo-$expect"
    
    
    not ok 10 - diff-filter=M

which leaves you with head-scratching (did log exit non-zero, or did the
comparison fail?). If we add in "-x", we get:

    expecting success: 

            actual=$(git log --pretty="format:%s" --diff-filter=M HEAD) &&
            expect=$(echo second) &&
            test "$actual" = "foo-$expect"
    
    
    + git log --pretty=format:%s --diff-filter=M HEAD
    + actual=second
    + echo second
    + expect=second
    + test second = foo-second
    error: last command exited with $?=1
    not ok 10 - diff-filter=M

That essentially gives us the same data, but with a lot of other cruft.
In this case, I don't think it's too bad (the test isn't that long), but
some of the "-x" cases can get pretty verbose. I guess things are a bit
better since I added the "last command exited..." in red, but I still
think the "verbose" version is the most straightforward.

Do we object to having to sprinkle the "verbose" throughout the test
scripts? IMHO it is not any worse than test_cmp. But if that is a
problem, would it be too magical to do something like:

  test () {
	verbose command test "$@"
  }

(but only inside the test snippets)?

-Peff

  reply	other threads:[~2015-05-16 15:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13  9:52 [PATCH 0/4] make pull.ff=true override merge.ff Paul Tan
2015-05-13  9:52 ` [PATCH 1/4] t7601: test for pull.ff=true overrides merge.ff=false Paul Tan
2015-05-14 13:06   ` Johannes Schindelin
2015-05-14 16:45     ` Junio C Hamano
2015-05-14 16:53       ` sh -x -i -v with continuous integration, was " Johannes Schindelin
2015-05-14 17:06         ` Junio C Hamano
2015-05-16 15:28           ` Jeff King [this message]
2015-05-16 19:07             ` Junio C Hamano
2015-05-18 18:45               ` Jeff King
2015-05-18 20:41                 ` Junio C Hamano
2015-05-18 20:50                   ` Jeff King
2015-05-18 20:58                     ` Junio C Hamano
2015-05-16 12:33         ` Paul Tan
2015-05-13  9:52 ` [PATCH 2/4] pull: make pull.ff=true override merge.ff Paul Tan
2015-05-13  9:52 ` [PATCH 3/4] Documentation/config.txt: clarify that pull.ff overrides merge.ff Paul Tan
2015-05-13  9:52 ` [PATCH 4/4] pull: parse pull.ff as a bool or string Paul Tan
2015-05-14 12:59 ` [PATCH 0/4] make pull.ff=true override merge.ff Johannes Schindelin
  -- strict thread matches above, loose matches on Subject: below --
2015-05-19 13:22 sh -x -i -v with continuous integration, was Re: [PATCH 1/4] t7601: test for pull.ff=true overrides merge.ff=false Johannes Schindelin

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=20150516152858.GA19269@peff.net \
    --to=peff@peff.net \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=pyokagan@gmail.com \
    --cc=sbeller@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.