[RFC/PATCH 02/10] test-lib: introduce test_line_count to measure files

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 31, 2010, 07:33 UTC
Message-ID: <20101031073350.GC11483@burratino>
In-Reply-To: <20101031072640.GA11483@burratino>

Some tests check their output with code like the following:

	test "$(git ls-files -u B | wc -l)" -eq 3 || {
		echo "BAD: should have left stages for B"
		return 1
	}

The verbose failure condition is used because test, unlike diff, does not print any useful information about the nature of the failure when it fails.

Introduce a test_line_count function to help. If used like

	git ls-files -u B >output &&
	test_line_count -eq 3 output

it will produce output like

	test_line_count: line count for output !-eq 3
	100644 b023018cabc396e7692c70bbf5784a93d3f738ab 2	hi.c
	100644 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 3	hi.c

on failure.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
I don't imagine this would be too helpful for new tests,
but the idiom is common enough in old tests that maybe I'm
wrong about that.

 t/README      |    4 ++++
 t/test-lib.sh |   22 ++++++++++++++++++++++
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/t/README b/t/README
index 2aceb67..1a78982 100644
--- a/t/README
+++ b/t/README
@@ -500,6 +500,10 @@ library for your script to use.
    <expected> file.  This behaves like "cmp" but produces more
    helpful output when the test is run with "-v" option.
 
+ - test_line_count (= | -lt | -ge | ...) <length> <file>
+
+   Check whether a file has the length it is expected to.
+
  - test_path_is_file <file> [<diagnosis>]
    test_path_is_dir <dir> [<diagnosis>]
    test_path_is_missing <path> [<diagnosis>]
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 87308f5..a417bdf 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -598,6 +598,28 @@ test_path_is_missing () {
 	fi
 }
 
+# test_line_count checks that a file has the number of lines it
+# ought to. For example:
+#
+#	test_expect_success 'produce exactly one line of output' '
+#		do something >output &&
+#		test_line_count = 1 output
+#	'
+#
+# is like "test $(wc -l <output) = 1" except that it passes the
+# output through when the number of lines is wrong.
+
+test_line_count () {
+	if test $# != 3
+	then
+		error "bug in the test script: not 3 parameters to test_line_count"
+	elif ! test $(wc -l <"$3") "$1" "$2"
+	then
+		echo "test_line_count: line count for $3 !$1 $2"
+		cat "$3"
+		return 1
+	fi
+}
 
 # This is not among top-level (test_expect_success | test_expect_failure)
 # but is a prefix that can be used in the test script, like:

-- 
1.7.2.3.557.gab647.dirty