git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: Johannes Sixt <j6t@kdbg.org>, Jeff King <peff@peff.net>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
	Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 3/2] test: factor out helper function test_must_contain
Date: Sat, 21 Nov 2015 10:35:24 +0100	[thread overview]
Message-ID: <56503ADC.50908@web.de> (raw)
In-Reply-To: <56502745.2000307@kdbg.org>

Am 21.11.2015 um 09:11 schrieb Johannes Sixt:
> Am 20.11.2015 um 21:50 schrieb René Scharfe:
>> Extract a helper function for searching for a pattern in a file and
>> printing the whole file if the pattern is not found.  It is useful
>> when starting tests with --verbose for debugging purposes.
> 
>> +# Check if a file contains an expected pattern.
>> +test_must_contain () {
>> +    if grep "$1" "$2"
>> +    then
>> +        return 0
>> +    else
>> +        echo "didn't find /$1/ in '$2', it contains:"
>> +        cat "$2"
>> +        return 1
>> +    fi
>> +}
> 
> There is already test_i18n_grep. Should it be folded into this function? 

That's a good point.  But how?  test_i18ngrep can also work as a
filter and pass on options, so we'd need to parse all parameters and
redirect stdin to a temporary file unless a file was specified.  Or
we could be sloppy and just check if the last parameter is a file and
if yes then spew it out.

> Wouldn't we also want to have a function test_must_not_contain?

I doubt it.  In such a function grep would display the lines that match
unexpectedly already, so showing the whole file after that won't add
much more of interest.

> IMHO, we should not increase the number of functions that give a bonus 
> only when there is a test case failure. They do not scale well: There is 
> a permanent mental burden on every reviewer to watch out that they are 
> used in new tests. But without those functions, the burden is on the one 
> person investigating a test case failure, who has to live without the 
> debugging support.

test_must_contain doesn't have to be used everywhere, only in cases
where a file is shown and grepped.  I agree that letting an existing
function do that job (or deciding that the job is not worth doing) is
preferable.

Here's how I imagine the sloppy add-on to test_i18ncmp to look:

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 16c4d7b..db64600 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -985,13 +985,28 @@ test_i18ncmp () {
 test_i18ngrep () {
 	if test -n "$GETTEXT_POISON"
 	then
 	    : # pretend success
 	elif test "x!" = "x$1"
 	then
 		shift
 		! grep "$@"
 	else
 		grep "$@"
+
+		rc=$?
+		if test $rc != 0
+		then
+			while test $# -gt 1
+			do
+				shift
+			done
+			if test -f "$1"
+			then
+				echo "Expected pattern not found, content is:"
+				cat "$1"
+			fi
+			return $rc
+		fi
 	fi
 }
 

  reply	other threads:[~2015-11-21  9:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-19 16:20 [PATCH 1/2] t1450: add tests for NUL in headers of commits and tags René Scharfe
2015-11-19 16:25 ` [PATCH 2/2] fsck: treat a NUL in a tag header as an error René Scharfe
2015-11-20 11:13   ` Jeff King
2015-11-20 20:18   ` Johannes Schindelin
2015-11-19 20:33 ` [PATCH 1/2] t1450: add tests for NUL in headers of commits and tags Eric Sunshine
2015-11-19 20:54   ` René Scharfe
2015-11-20 11:14     ` Jeff King
2015-11-20 20:49       ` René Scharfe
2015-11-20 20:50       ` [PATCH 3/2] test: factor out helper function test_must_contain René Scharfe
2015-11-21  8:11         ` Johannes Sixt
2015-11-21  9:35           ` René Scharfe [this message]
2015-11-20 20:50       ` [PATCH 4/2] test: use test_must_contain René Scharfe
2015-11-21  1:16         ` SZEDER Gábor
2015-11-21  2:30           ` René Scharfe

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=56503ADC.50908@web.de \
    --to=l.s.r@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).