2005-05-14 07:50:32 +02:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2005 Junio C Hamano
|
|
|
|
#
|
2010-04-16 15:53:59 +02:00
|
|
|
# This program is free software: you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation, either version 2 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see http://www.gnu.org/licenses/ .
|
2005-05-14 07:50:32 +02:00
|
|
|
|
test-lib.sh: optionally output to test-results/$TEST.out, too
When tests are run in parallel and a few tests fail, it does not help
that the output of the terminal is totally confusing, as you rarely know
which test which line came from.
So introduce the option '--tee' which triggers that the output of the
tests will be written to t/test-results/$TEST.out in addition to the
terminal, where $TEST is the basename of the script.
Unfortunately, there seems to be no way to redirect a given file
descriptor to a specified subprocess in POSIX shell, only redirection
to a file is supported via 'exec > $FILE'.
At least with bash, one might think that 'exec >($COMMAND)' would work
as intended, but it does not.
The common way to work around the lack of proper tools support is to
work with named pipes, alas, one of our most beloved platforms does not
really support named pipes. Besides, we would need a pipe for every
script, as the whole point of this patch is to allow parallel execution.
Therefore, we handle the redirection in the following way: when '--tee'
was passed to the test script, the variable GIT_TEST_TEE_STARTED is set
(to avoid triggering that code path again) and the script is started
_again_, in a subshell, redirected to the command "tee".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-04 00:26:12 +01:00
|
|
|
# if --tee was passed, write the output not only to the terminal, but
|
|
|
|
# additionally to the file test-results/$BASENAME.out, too.
|
|
|
|
case "$GIT_TEST_TEE_STARTED, $* " in
|
|
|
|
done,*)
|
|
|
|
# do not redirect again
|
|
|
|
;;
|
2009-02-04 00:26:26 +01:00
|
|
|
*' --tee '*|*' --va'*)
|
test-lib.sh: optionally output to test-results/$TEST.out, too
When tests are run in parallel and a few tests fail, it does not help
that the output of the terminal is totally confusing, as you rarely know
which test which line came from.
So introduce the option '--tee' which triggers that the output of the
tests will be written to t/test-results/$TEST.out in addition to the
terminal, where $TEST is the basename of the script.
Unfortunately, there seems to be no way to redirect a given file
descriptor to a specified subprocess in POSIX shell, only redirection
to a file is supported via 'exec > $FILE'.
At least with bash, one might think that 'exec >($COMMAND)' would work
as intended, but it does not.
The common way to work around the lack of proper tools support is to
work with named pipes, alas, one of our most beloved platforms does not
really support named pipes. Besides, we would need a pipe for every
script, as the whole point of this patch is to allow parallel execution.
Therefore, we handle the redirection in the following way: when '--tee'
was passed to the test script, the variable GIT_TEST_TEE_STARTED is set
(to avoid triggering that code path again) and the script is started
_again_, in a subshell, redirected to the command "tee".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-04 00:26:12 +01:00
|
|
|
mkdir -p test-results
|
|
|
|
BASE=test-results/$(basename "$0" .sh)
|
|
|
|
(GIT_TEST_TEE_STARTED=done ${SHELL-sh} "$0" "$@" 2>&1;
|
|
|
|
echo $? > $BASE.exit) | tee $BASE.out
|
|
|
|
test "$(cat $BASE.exit)" = 0
|
|
|
|
exit
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2008-03-07 04:04:26 +01:00
|
|
|
# Keep the original TERM for say_color
|
|
|
|
ORIGINAL_TERM=$TERM
|
|
|
|
|
2005-05-14 07:50:32 +02:00
|
|
|
# For repeatability, reset the environment to known value.
|
|
|
|
LANG=C
|
2005-10-10 06:58:02 +02:00
|
|
|
LC_ALL=C
|
2005-08-11 04:10:01 +02:00
|
|
|
PAGER=cat
|
2005-05-14 07:50:32 +02:00
|
|
|
TZ=UTC
|
2008-03-07 04:04:26 +01:00
|
|
|
TERM=dumb
|
|
|
|
export LANG LC_ALL PAGER TERM TZ
|
2006-07-11 21:01:54 +02:00
|
|
|
EDITOR=:
|
Do not use VISUAL editor on dumb terminals
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:56:07 +01:00
|
|
|
unset VISUAL
|
2007-04-29 03:40:28 +02:00
|
|
|
unset EMAIL
|
i18n: add infrastructure for translating Git with gettext
Change the skeleton implementation of i18n in Git to one that can show
localized strings to users for our C, Shell and Perl programs using
either GNU libintl or the Solaris gettext implementation.
This new internationalization support is enabled by default. If
gettext isn't available, or if Git is compiled with
NO_GETTEXT=YesPlease, Git falls back on its current behavior of
showing interface messages in English. When using the autoconf script
we'll auto-detect if the gettext libraries are installed and act
appropriately.
This change is somewhat large because as well as adding a C, Shell and
Perl i18n interface we're adding a lot of tests for them, and for
those tests to work we need a skeleton PO file to actually test
translations. A minimal Icelandic translation is included for this
purpose. Icelandic includes multi-byte characters which makes it easy
to test various edge cases, and it's a language I happen to
understand.
The rest of the commit message goes into detail about various
sub-parts of this commit.
= Installation
Gettext .mo files will be installed and looked for in the standard
$(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
override that, but that's only intended to be used to test Git itself.
= Perl
Perl code that's to be localized should use the new Git::I18n
module. It imports a __ function into the caller's package by default.
Instead of using the high level Locale::TextDomain interface I've
opted to use the low-level (equivalent to the C interface)
Locale::Messages module, which Locale::TextDomain itself uses.
Locale::TextDomain does a lot of redundant work we don't need, and
some of it would potentially introduce bugs. It tries to set the
$TEXTDOMAIN based on package of the caller, and has its own
hardcoded paths where it'll search for messages.
I found it easier just to completely avoid it rather than try to
circumvent its behavior. In any case, this is an issue wholly
internal Git::I18N. Its guts can be changed later if that's deemed
necessary.
See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
a further elaboration on this topic.
= Shell
Shell code that's to be localized should use the git-sh-i18n
library. It's basically just a wrapper for the system's gettext.sh.
If gettext.sh isn't available we'll fall back on gettext(1) if it's
available. The latter is available without the former on Solaris,
which has its own non-GNU gettext implementation. We also need to
emulate eval_gettext() there.
If neither are present we'll use a dumb printf(1) fall-through
wrapper.
= About libcharset.h and langinfo.h
We use libcharset to query the character set of the current locale if
it's available. I.e. we'll use it instead of nl_langinfo if
HAVE_LIBCHARSET_H is set.
The GNU gettext manual recommends using langinfo.h's
nl_langinfo(CODESET) to acquire the current character set, but on
systems that have libcharset.h's locale_charset() using the latter is
either saner, or the only option on those systems.
GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
but MinGW and some others need to use libcharset.h's locale_charset()
instead.
=Credits
This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
did the initial Makefile / C work, and a lot of comments from the Git
mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
others.
[jc: squashed a small Makefile fix from Ramsay]
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-18 00:14:42 +01:00
|
|
|
unset LANGUAGE
|
2011-03-15 11:10:45 +01:00
|
|
|
unset $(perl -e '
|
|
|
|
my @env = keys %ENV;
|
2011-03-28 21:16:09 +02:00
|
|
|
my $ok = join("|", qw(
|
|
|
|
TRACE
|
|
|
|
DEBUG
|
|
|
|
USE_LOOKUP
|
|
|
|
TEST
|
|
|
|
.*_TEST
|
|
|
|
PROVE
|
|
|
|
VALGRIND
|
|
|
|
));
|
|
|
|
my @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);
|
2011-03-15 11:10:45 +01:00
|
|
|
print join("\n", @vars);
|
|
|
|
')
|
2006-02-11 04:11:23 +01:00
|
|
|
GIT_AUTHOR_EMAIL=author@example.com
|
|
|
|
GIT_AUTHOR_NAME='A U Thor'
|
|
|
|
GIT_COMMITTER_EMAIL=committer@example.com
|
|
|
|
GIT_COMMITTER_NAME='C O Mitter'
|
2007-02-04 06:45:47 +01:00
|
|
|
GIT_MERGE_VERBOSITY=5
|
|
|
|
export GIT_MERGE_VERBOSITY
|
2006-02-11 04:11:23 +01:00
|
|
|
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
|
|
|
|
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
|
Do not use VISUAL editor on dumb terminals
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:56:07 +01:00
|
|
|
export EDITOR
|
2005-05-14 07:50:32 +02:00
|
|
|
|
2007-04-24 20:21:47 +02:00
|
|
|
# Protect ourselves from common misconfiguration to export
|
|
|
|
# CDPATH into the environment
|
|
|
|
unset CDPATH
|
|
|
|
|
2009-11-18 17:15:19 +01:00
|
|
|
unset GREP_OPTIONS
|
|
|
|
|
2006-09-23 00:35:20 +02:00
|
|
|
case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
|
2006-09-02 18:23:48 +02:00
|
|
|
1|2|true)
|
|
|
|
echo "* warning: Some tests will not work if GIT_TRACE" \
|
|
|
|
"is set as to trace on STDERR ! *"
|
|
|
|
echo "* warning: Please set GIT_TRACE to something" \
|
|
|
|
"other than 1, 2 or true ! *"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2009-09-20 20:10:14 +02:00
|
|
|
# Convenience
|
|
|
|
#
|
|
|
|
# A regexp to match 5 and 40 hexdigits
|
|
|
|
_x05='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
|
|
|
|
_x40="$_x05$_x05$_x05$_x05$_x05$_x05$_x05$_x05"
|
|
|
|
|
2011-04-24 07:34:13 +02:00
|
|
|
# Zero SHA-1
|
|
|
|
_z40=0000000000000000000000000000000000000000
|
|
|
|
|
2011-08-08 20:51:00 +02:00
|
|
|
# Line feed
|
|
|
|
LF='
|
|
|
|
'
|
|
|
|
|
2005-05-14 07:50:32 +02:00
|
|
|
# Each test should start with something like this, after copyright notices:
|
|
|
|
#
|
|
|
|
# test_description='Description of this test...
|
|
|
|
# This test checks if command xyzzy does the right thing...
|
|
|
|
# '
|
|
|
|
# . ./test-lib.sh
|
2008-03-07 04:04:26 +01:00
|
|
|
[ "x$ORIGINAL_TERM" != "xdumb" ] && (
|
|
|
|
TERM=$ORIGINAL_TERM &&
|
|
|
|
export TERM &&
|
|
|
|
[ -t 1 ] &&
|
|
|
|
tput bold >/dev/null 2>&1 &&
|
|
|
|
tput setaf 1 >/dev/null 2>&1 &&
|
|
|
|
tput sgr0 >/dev/null 2>&1
|
|
|
|
) &&
|
2007-10-24 22:03:38 +02:00
|
|
|
color=t
|
2005-05-14 07:50:32 +02:00
|
|
|
|
|
|
|
while test "$#" -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-d|--d|--de|--deb|--debu|--debug)
|
|
|
|
debug=t; shift ;;
|
2005-05-14 09:24:27 +02:00
|
|
|
-i|--i|--im|--imm|--imme|--immed|--immedi|--immedia|--immediat|--immediate)
|
|
|
|
immediate=t; shift ;;
|
2008-06-17 03:29:02 +02:00
|
|
|
-l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
|
2009-02-18 20:17:27 +01:00
|
|
|
GIT_TEST_LONG=t; export GIT_TEST_LONG; shift ;;
|
2005-05-14 07:50:32 +02:00
|
|
|
-h|--h|--he|--hel|--help)
|
2007-11-10 15:17:25 +01:00
|
|
|
help=t; shift ;;
|
2005-05-14 07:50:32 +02:00
|
|
|
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
|
|
|
|
verbose=t; shift ;;
|
2007-10-24 22:03:39 +02:00
|
|
|
-q|--q|--qu|--qui|--quie|--quiet)
|
2010-07-31 18:40:05 +02:00
|
|
|
# Ignore --quiet under a TAP::Harness. Saying how many tests
|
|
|
|
# passed without the ok/not ok details is always an error.
|
|
|
|
test -z "$HARNESS_ACTIVE" && quiet=t; shift ;;
|
2009-12-03 06:14:06 +01:00
|
|
|
--with-dashes)
|
|
|
|
with_dashes=t; shift ;;
|
2007-10-24 22:03:38 +02:00
|
|
|
--no-color)
|
2008-02-27 20:28:45 +01:00
|
|
|
color=; shift ;;
|
2009-02-04 00:25:59 +01:00
|
|
|
--va|--val|--valg|--valgr|--valgri|--valgrin|--valgrind)
|
2009-02-04 00:26:26 +01:00
|
|
|
valgrind=t; verbose=t; shift ;;
|
test-lib.sh: optionally output to test-results/$TEST.out, too
When tests are run in parallel and a few tests fail, it does not help
that the output of the terminal is totally confusing, as you rarely know
which test which line came from.
So introduce the option '--tee' which triggers that the output of the
tests will be written to t/test-results/$TEST.out in addition to the
terminal, where $TEST is the basename of the script.
Unfortunately, there seems to be no way to redirect a given file
descriptor to a specified subprocess in POSIX shell, only redirection
to a file is supported via 'exec > $FILE'.
At least with bash, one might think that 'exec >($COMMAND)' would work
as intended, but it does not.
The common way to work around the lack of proper tools support is to
work with named pipes, alas, one of our most beloved platforms does not
really support named pipes. Besides, we would need a pipe for every
script, as the whole point of this patch is to allow parallel execution.
Therefore, we handle the redirection in the following way: when '--tee'
was passed to the test script, the variable GIT_TEST_TEE_STARTED is set
(to avoid triggering that code path again) and the script is started
_again_, in a subshell, redirected to the command "tee".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-04 00:26:12 +01:00
|
|
|
--tee)
|
|
|
|
shift ;; # was handled already
|
2009-08-09 10:39:45 +02:00
|
|
|
--root=*)
|
|
|
|
root=$(expr "z$1" : 'z[^=]*=\(.*\)')
|
|
|
|
shift ;;
|
2005-05-14 07:50:32 +02:00
|
|
|
*)
|
2009-06-01 14:14:40 +02:00
|
|
|
echo "error: unknown test option '$1'" >&2; exit 1 ;;
|
2005-05-14 07:50:32 +02:00
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
2007-10-24 22:03:38 +02:00
|
|
|
if test -n "$color"; then
|
|
|
|
say_color () {
|
2008-03-07 04:04:26 +01:00
|
|
|
(
|
|
|
|
TERM=$ORIGINAL_TERM
|
|
|
|
export TERM
|
2007-10-24 22:03:38 +02:00
|
|
|
case "$1" in
|
|
|
|
error) tput bold; tput setaf 1;; # bold red
|
|
|
|
skip) tput bold; tput setaf 2;; # bold green
|
|
|
|
pass) tput setaf 2;; # green
|
|
|
|
info) tput setaf 3;; # brown
|
2007-10-24 22:03:39 +02:00
|
|
|
*) test -n "$quiet" && return;;
|
2007-10-24 22:03:38 +02:00
|
|
|
esac
|
|
|
|
shift
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
printf "%s" "$*"
|
2007-10-24 22:03:38 +02:00
|
|
|
tput sgr0
|
2008-10-10 00:07:10 +02:00
|
|
|
echo
|
2008-03-07 04:04:26 +01:00
|
|
|
)
|
2007-10-24 22:03:38 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
say_color() {
|
2007-10-24 22:03:39 +02:00
|
|
|
test -z "$1" && test -n "$quiet" && return
|
2007-10-24 22:03:38 +02:00
|
|
|
shift
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
echo "$*"
|
2007-10-24 22:03:38 +02:00
|
|
|
}
|
|
|
|
fi
|
|
|
|
|
|
|
|
error () {
|
|
|
|
say_color error "error: $*"
|
2009-06-01 14:14:41 +02:00
|
|
|
GIT_EXIT_OK=t
|
2007-10-24 22:03:38 +02:00
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
|
|
|
|
say () {
|
|
|
|
say_color info "$*"
|
|
|
|
}
|
|
|
|
|
2007-11-10 15:17:25 +01:00
|
|
|
test "${test_description}" != "" ||
|
|
|
|
error "Test script did not set test_description."
|
|
|
|
|
|
|
|
if test "$help" = "t"
|
|
|
|
then
|
|
|
|
echo "$test_description"
|
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
|
2005-08-11 05:56:21 +02:00
|
|
|
exec 5>&1
|
test-lib: redirect stdin of tests
We want to run tests in a predictable, sterile environment
so we can get repeatable results. They should take as
little input as possible from the environment outside the
test script. We already sanitize environment variables, but
leave stdin untouched. This means that scripts can
accidentally be impacted by content on stdin, or whether
stdin isatty().
Furthermore, scripts reading from stdin can be annoying to
outer loops which care about their stdin offset, like:
while read sha1; do
make test
done
A test which accidentally reads stdin would soak up all of
the rest of the input intended for the outer shell loop.
Let's redirect stdin from /dev/null, which solves both
of these problems. It won't detect tests accidentally
reading from stdin, but since doing so now gives a
deterministic result, we don't need to consider that an
error.
We'll also leave file descriptor 6 as a link to the original
stdin. Tests shouldn't need to look at this, but it can be
convenient for inserting interactive commands while
debugging tests (e.g., you could insert "bash <&6 >&3 2>&4"
to run interactive commands in the environment of the test
script).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15 07:55:29 +01:00
|
|
|
exec 6<&0
|
2005-05-14 07:50:32 +02:00
|
|
|
if test "$verbose" = "t"
|
|
|
|
then
|
|
|
|
exec 4>&2 3>&1
|
|
|
|
else
|
|
|
|
exec 4>/dev/null 3>/dev/null
|
|
|
|
fi
|
|
|
|
|
|
|
|
test_failure=0
|
|
|
|
test_count=0
|
2008-02-01 10:50:53 +01:00
|
|
|
test_fixed=0
|
|
|
|
test_broken=0
|
2008-06-08 16:04:33 +02:00
|
|
|
test_success=0
|
2005-05-14 07:50:32 +02:00
|
|
|
|
2010-06-24 19:44:46 +02:00
|
|
|
test_external_has_tap=0
|
|
|
|
|
2008-02-27 20:28:45 +01:00
|
|
|
die () {
|
2009-06-01 14:14:41 +02:00
|
|
|
code=$?
|
|
|
|
if test -n "$GIT_EXIT_OK"
|
|
|
|
then
|
|
|
|
exit $code
|
|
|
|
else
|
|
|
|
echo >&5 "FATAL: Unexpected exit with code $code"
|
|
|
|
exit 1
|
|
|
|
fi
|
2008-02-27 20:28:45 +01:00
|
|
|
}
|
|
|
|
|
2009-06-01 14:14:41 +02:00
|
|
|
GIT_EXIT_OK=
|
2009-01-20 00:43:26 +01:00
|
|
|
trap 'die' EXIT
|
2005-08-11 18:00:40 +02:00
|
|
|
|
2008-05-04 07:37:54 +02:00
|
|
|
# The semantics of the editor variables are that of invoking
|
|
|
|
# sh -c "$EDITOR \"$@\"" files ...
|
|
|
|
#
|
|
|
|
# If our trash directory contains shell metacharacters, they will be
|
|
|
|
# interpreted if we just set $EDITOR directly, so do a little dance with
|
|
|
|
# environment variables to work around this.
|
|
|
|
#
|
|
|
|
# In particular, quoting isn't enough, as the path may contain the same quote
|
2008-06-13 00:35:59 +02:00
|
|
|
# that we're using.
|
2008-05-04 07:37:54 +02:00
|
|
|
test_set_editor () {
|
|
|
|
FAKE_EDITOR="$1"
|
|
|
|
export FAKE_EDITOR
|
Do not use VISUAL editor on dumb terminals
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:56:07 +01:00
|
|
|
EDITOR='"$FAKE_EDITOR"'
|
|
|
|
export EDITOR
|
2008-05-04 07:37:54 +02:00
|
|
|
}
|
|
|
|
|
2009-12-08 11:12:02 +01:00
|
|
|
test_decode_color () {
|
2010-10-21 00:17:25 +02:00
|
|
|
awk '
|
|
|
|
function name(n) {
|
|
|
|
if (n == 0) return "RESET";
|
|
|
|
if (n == 1) return "BOLD";
|
|
|
|
if (n == 30) return "BLACK";
|
|
|
|
if (n == 31) return "RED";
|
|
|
|
if (n == 32) return "GREEN";
|
|
|
|
if (n == 33) return "YELLOW";
|
|
|
|
if (n == 34) return "BLUE";
|
|
|
|
if (n == 35) return "MAGENTA";
|
|
|
|
if (n == 36) return "CYAN";
|
|
|
|
if (n == 37) return "WHITE";
|
|
|
|
if (n == 40) return "BLACK";
|
|
|
|
if (n == 41) return "BRED";
|
|
|
|
if (n == 42) return "BGREEN";
|
|
|
|
if (n == 43) return "BYELLOW";
|
|
|
|
if (n == 44) return "BBLUE";
|
|
|
|
if (n == 45) return "BMAGENTA";
|
|
|
|
if (n == 46) return "BCYAN";
|
|
|
|
if (n == 47) return "BWHITE";
|
|
|
|
}
|
|
|
|
{
|
2010-12-23 00:58:52 +01:00
|
|
|
while (match($0, /\033\[[0-9;]*m/) != 0) {
|
2010-10-21 00:17:25 +02:00
|
|
|
printf "%s<", substr($0, 1, RSTART-1);
|
|
|
|
codes = substr($0, RSTART+2, RLENGTH-3);
|
|
|
|
if (length(codes) == 0)
|
|
|
|
printf "%s", name(0)
|
|
|
|
else {
|
|
|
|
n = split(codes, ary, ";");
|
|
|
|
sep = "";
|
|
|
|
for (i = 1; i <= n; i++) {
|
|
|
|
printf "%s%s", sep, name(ary[i]);
|
|
|
|
sep = ";"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
printf ">";
|
|
|
|
$0 = substr($0, RSTART + RLENGTH, length($0) - RSTART - RLENGTH + 1);
|
|
|
|
}
|
|
|
|
print
|
|
|
|
}
|
|
|
|
'
|
2009-12-08 11:12:02 +01:00
|
|
|
}
|
|
|
|
|
2010-10-07 20:25:43 +02:00
|
|
|
nul_to_q () {
|
|
|
|
perl -pe 'y/\000/Q/'
|
|
|
|
}
|
|
|
|
|
2010-01-26 01:33:57 +01:00
|
|
|
q_to_nul () {
|
|
|
|
perl -pe 'y/Q/\000/'
|
|
|
|
}
|
|
|
|
|
|
|
|
q_to_cr () {
|
|
|
|
tr Q '\015'
|
|
|
|
}
|
|
|
|
|
2010-07-23 19:03:07 +02:00
|
|
|
q_to_tab () {
|
|
|
|
tr Q '\011'
|
|
|
|
}
|
|
|
|
|
2010-01-26 01:33:57 +01:00
|
|
|
append_cr () {
|
|
|
|
sed -e 's/$/Q/' | tr Q '\015'
|
|
|
|
}
|
|
|
|
|
|
|
|
remove_cr () {
|
|
|
|
tr '\015' Q | sed -e 's/Q$//'
|
|
|
|
}
|
|
|
|
|
2010-10-03 22:00:14 +02:00
|
|
|
# In some bourne shell implementations, the "unset" builtin returns
|
|
|
|
# nonzero status when a variable to be unset was not set in the first
|
|
|
|
# place.
|
|
|
|
#
|
|
|
|
# Use sane_unset when that should not be considered an error.
|
|
|
|
|
|
|
|
sane_unset () {
|
|
|
|
unset "$@"
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2006-12-29 11:25:04 +01:00
|
|
|
test_tick () {
|
|
|
|
if test -z "${test_tick+set}"
|
|
|
|
then
|
2007-01-06 11:16:07 +01:00
|
|
|
test_tick=1112911993
|
2006-12-29 11:25:04 +01:00
|
|
|
else
|
|
|
|
test_tick=$(($test_tick + 60))
|
|
|
|
fi
|
2007-01-06 11:16:07 +01:00
|
|
|
GIT_COMMITTER_DATE="$test_tick -0700"
|
|
|
|
GIT_AUTHOR_DATE="$test_tick -0700"
|
2006-12-29 11:25:04 +01:00
|
|
|
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
|
|
|
|
}
|
2005-05-14 07:50:32 +02:00
|
|
|
|
2009-01-27 23:34:48 +01:00
|
|
|
# Call test_commit with the arguments "<message> [<file> [<contents>]]"
|
|
|
|
#
|
|
|
|
# This will commit a file with the given contents and the given commit
|
|
|
|
# message. It will also add a tag with <message> as name.
|
|
|
|
#
|
|
|
|
# Both <file> and <contents> default to <message>.
|
|
|
|
|
|
|
|
test_commit () {
|
2009-02-04 06:46:33 +01:00
|
|
|
file=${2:-"$1.t"}
|
2009-01-27 23:34:48 +01:00
|
|
|
echo "${3-$1}" > "$file" &&
|
|
|
|
git add "$file" &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m "$1" &&
|
|
|
|
git tag "$1"
|
|
|
|
}
|
|
|
|
|
|
|
|
# Call test_merge with the arguments "<message> <commit>", where <commit>
|
|
|
|
# can be a tag pointing to the commit-to-merge.
|
|
|
|
|
|
|
|
test_merge () {
|
|
|
|
test_tick &&
|
|
|
|
git merge -m "$1" "$2" &&
|
|
|
|
git tag "$1"
|
|
|
|
}
|
|
|
|
|
2009-02-28 21:12:57 +01:00
|
|
|
# This function helps systems where core.filemode=false is set.
|
|
|
|
# Use it instead of plain 'chmod +x' to set or unset the executable bit
|
|
|
|
# of a file in the working directory and add it to the index.
|
|
|
|
|
|
|
|
test_chmod () {
|
|
|
|
chmod "$@" &&
|
|
|
|
git update-index --add "--chmod=$@"
|
|
|
|
}
|
|
|
|
|
2011-08-18 07:01:15 +02:00
|
|
|
# Unset a configuration variable, but don't fail if it doesn't exist.
|
|
|
|
test_unconfig () {
|
|
|
|
git config --unset-all "$@"
|
|
|
|
config_status=$?
|
|
|
|
case "$config_status" in
|
|
|
|
5) # ok, nothing to unset
|
|
|
|
config_status=0
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
return $config_status
|
|
|
|
}
|
|
|
|
|
|
|
|
# Set git config, automatically unsetting it after the test is over.
|
|
|
|
test_config () {
|
|
|
|
test_when_finished "test_unconfig '$1'" &&
|
|
|
|
git config "$@"
|
|
|
|
}
|
|
|
|
|
2012-02-04 07:29:01 +01:00
|
|
|
|
2011-12-10 11:30:06 +01:00
|
|
|
test_config_global () {
|
|
|
|
test_when_finished "test_unconfig --global '$1'" &&
|
|
|
|
git config --global "$@"
|
|
|
|
}
|
|
|
|
|
2012-02-04 07:29:01 +01:00
|
|
|
write_script () {
|
|
|
|
{
|
|
|
|
echo "#!${2-"$SHELL_PATH"}" &&
|
|
|
|
cat
|
|
|
|
} >"$1" &&
|
|
|
|
chmod +x "$1"
|
|
|
|
}
|
|
|
|
|
2009-03-01 21:04:46 +01:00
|
|
|
# Use test_set_prereq to tell that a particular prerequisite is available.
|
|
|
|
# The prerequisite can later be checked for in two ways:
|
|
|
|
#
|
|
|
|
# - Explicitly using test_have_prereq.
|
|
|
|
#
|
|
|
|
# - Implicitly by specifying the prerequisite tag in the calls to
|
|
|
|
# test_expect_{success,failure,code}.
|
|
|
|
#
|
|
|
|
# The single parameter is the prerequisite tag (a simple word, in all
|
|
|
|
# capital letters by convention).
|
|
|
|
|
|
|
|
test_set_prereq () {
|
|
|
|
satisfied="$satisfied$1 "
|
|
|
|
}
|
|
|
|
satisfied=" "
|
|
|
|
|
|
|
|
test_have_prereq () {
|
2010-08-06 23:19:23 +02:00
|
|
|
# prerequisites can be concatenated with ','
|
|
|
|
save_IFS=$IFS
|
|
|
|
IFS=,
|
|
|
|
set -- $*
|
|
|
|
IFS=$save_IFS
|
2010-08-11 14:04:38 +02:00
|
|
|
|
|
|
|
total_prereq=0
|
|
|
|
ok_prereq=0
|
|
|
|
missing_prereq=
|
|
|
|
|
2010-08-06 23:19:23 +02:00
|
|
|
for prerequisite
|
|
|
|
do
|
2010-08-11 14:04:38 +02:00
|
|
|
total_prereq=$(($total_prereq + 1))
|
2010-08-06 23:19:23 +02:00
|
|
|
case $satisfied in
|
|
|
|
*" $prerequisite "*)
|
2010-08-11 14:04:38 +02:00
|
|
|
ok_prereq=$(($ok_prereq + 1))
|
|
|
|
;;
|
2010-08-06 23:19:23 +02:00
|
|
|
*)
|
2010-08-11 14:04:38 +02:00
|
|
|
# Keep a list of missing prerequisites
|
|
|
|
if test -z "$missing_prereq"
|
|
|
|
then
|
|
|
|
missing_prereq=$prerequisite
|
|
|
|
else
|
|
|
|
missing_prereq="$prerequisite,$missing_prereq"
|
|
|
|
fi
|
2010-08-06 23:19:23 +02:00
|
|
|
esac
|
|
|
|
done
|
2010-08-11 14:04:38 +02:00
|
|
|
|
|
|
|
test $total_prereq = $ok_prereq
|
2009-03-01 21:04:46 +01:00
|
|
|
}
|
|
|
|
|
2010-10-16 20:36:58 +02:00
|
|
|
test_declared_prereq () {
|
|
|
|
case ",$test_prereq," in
|
|
|
|
*,$1,*)
|
|
|
|
return 0
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2005-05-14 09:24:27 +02:00
|
|
|
# You are not expected to call test_ok_ and test_failure_ directly, use
|
|
|
|
# the text_expect_* functions instead.
|
|
|
|
|
|
|
|
test_ok_ () {
|
2009-02-05 20:59:27 +01:00
|
|
|
test_success=$(($test_success + 1))
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
say_color "" "ok $test_count - $@"
|
2005-05-14 07:50:32 +02:00
|
|
|
}
|
|
|
|
|
2005-05-14 09:24:27 +02:00
|
|
|
test_failure_ () {
|
2009-02-05 20:59:27 +01:00
|
|
|
test_failure=$(($test_failure + 1))
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
say_color error "not ok - $test_count $1"
|
2005-07-23 04:09:34 +02:00
|
|
|
shift
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
echo "$@" | sed -e 's/^/# /'
|
2009-06-01 14:14:41 +02:00
|
|
|
test "$immediate" = "" || { GIT_EXIT_OK=t; exit 1; }
|
2005-05-14 09:24:27 +02:00
|
|
|
}
|
|
|
|
|
2008-02-01 10:50:53 +01:00
|
|
|
test_known_broken_ok_ () {
|
|
|
|
test_fixed=$(($test_fixed+1))
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
say_color "" "ok $test_count - $@ # TODO known breakage"
|
2008-02-01 10:50:53 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
test_known_broken_failure_ () {
|
|
|
|
test_broken=$(($test_broken+1))
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
say_color skip "not ok $test_count - $@ # TODO known breakage"
|
2008-02-01 10:50:53 +01:00
|
|
|
}
|
2005-05-14 09:24:27 +02:00
|
|
|
|
|
|
|
test_debug () {
|
2005-08-11 07:53:27 +02:00
|
|
|
test "$debug" = "" || eval "$1"
|
2005-05-14 07:50:32 +02:00
|
|
|
}
|
|
|
|
|
test: cope better with use of return for errors
In olden times, tests would quietly exit the script when they failed
at an inconvenient moment, which was a little disconcerting.
Therefore v0.99.5~24^2~4 (Trapping exit in tests, using return for
errors, 2005-08-10) switched to an idiom of using "return" instead,
wrapping evaluation of test code in a function to make that safe:
test_run_ () {
eval >&3 2>&4 "$1"
eval_ret="$?"
return 0
}
Years later, the implementation of test_when_finished (v1.7.1.1~95,
2010-05-02) and v1.7.2-rc2~1^2~13 (test-lib: output a newline before
"ok" under a TAP harness, 2010-06-24) took advantage of test_run_ as a
place to put code shared by all test assertion functions, without
paying attention to the function's former purpose:
test_run_ () {
...
eval >&3 2>&4 "$1"
eval_ret=$?
if should run cleanup
then
eval >&3 2>&4 "$test_cleanup"
fi
if TAP format requires a newline here
then
echo
fi
return 0
}
That means cleanup commands and the newline to put TAP output at
column 0 are skipped when tests use "return" to fail early. Fix it by
introducing a test_eval_ function to catch the "return", with a
comment explaining the new function's purpose for the next person who
might touch this code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 03:17:09 +02:00
|
|
|
test_eval_ () {
|
|
|
|
# This is a separate function because some tests use
|
|
|
|
# "return" to end a test_expect_success block early.
|
test-lib: redirect stdin of tests
We want to run tests in a predictable, sterile environment
so we can get repeatable results. They should take as
little input as possible from the environment outside the
test script. We already sanitize environment variables, but
leave stdin untouched. This means that scripts can
accidentally be impacted by content on stdin, or whether
stdin isatty().
Furthermore, scripts reading from stdin can be annoying to
outer loops which care about their stdin offset, like:
while read sha1; do
make test
done
A test which accidentally reads stdin would soak up all of
the rest of the input intended for the outer shell loop.
Let's redirect stdin from /dev/null, which solves both
of these problems. It won't detect tests accidentally
reading from stdin, but since doing so now gives a
deterministic result, we don't need to consider that an
error.
We'll also leave file descriptor 6 as a link to the original
stdin. Tests shouldn't need to look at this, but it can be
convenient for inserting interactive commands while
debugging tests (e.g., you could insert "bash <&6 >&3 2>&4"
to run interactive commands in the environment of the test
script).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15 07:55:29 +01:00
|
|
|
eval </dev/null >&3 2>&4 "$*"
|
test: cope better with use of return for errors
In olden times, tests would quietly exit the script when they failed
at an inconvenient moment, which was a little disconcerting.
Therefore v0.99.5~24^2~4 (Trapping exit in tests, using return for
errors, 2005-08-10) switched to an idiom of using "return" instead,
wrapping evaluation of test code in a function to make that safe:
test_run_ () {
eval >&3 2>&4 "$1"
eval_ret="$?"
return 0
}
Years later, the implementation of test_when_finished (v1.7.1.1~95,
2010-05-02) and v1.7.2-rc2~1^2~13 (test-lib: output a newline before
"ok" under a TAP harness, 2010-06-24) took advantage of test_run_ as a
place to put code shared by all test assertion functions, without
paying attention to the function's former purpose:
test_run_ () {
...
eval >&3 2>&4 "$1"
eval_ret=$?
if should run cleanup
then
eval >&3 2>&4 "$test_cleanup"
fi
if TAP format requires a newline here
then
echo
fi
return 0
}
That means cleanup commands and the newline to put TAP output at
column 0 are skipped when tests use "return" to fail early. Fix it by
introducing a test_eval_ function to catch the "return", with a
comment explaining the new function's purpose for the next person who
might touch this code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 03:17:09 +02:00
|
|
|
}
|
|
|
|
|
2005-08-11 05:56:21 +02:00
|
|
|
test_run_ () {
|
2010-05-06 10:41:10 +02:00
|
|
|
test_cleanup=:
|
2011-06-27 20:02:22 +02:00
|
|
|
expecting_failure=$2
|
test: cope better with use of return for errors
In olden times, tests would quietly exit the script when they failed
at an inconvenient moment, which was a little disconcerting.
Therefore v0.99.5~24^2~4 (Trapping exit in tests, using return for
errors, 2005-08-10) switched to an idiom of using "return" instead,
wrapping evaluation of test code in a function to make that safe:
test_run_ () {
eval >&3 2>&4 "$1"
eval_ret="$?"
return 0
}
Years later, the implementation of test_when_finished (v1.7.1.1~95,
2010-05-02) and v1.7.2-rc2~1^2~13 (test-lib: output a newline before
"ok" under a TAP harness, 2010-06-24) took advantage of test_run_ as a
place to put code shared by all test assertion functions, without
paying attention to the function's former purpose:
test_run_ () {
...
eval >&3 2>&4 "$1"
eval_ret=$?
if should run cleanup
then
eval >&3 2>&4 "$test_cleanup"
fi
if TAP format requires a newline here
then
echo
fi
return 0
}
That means cleanup commands and the newline to put TAP output at
column 0 are skipped when tests use "return" to fail early. Fix it by
introducing a test_eval_ function to catch the "return", with a
comment explaining the new function's purpose for the next person who
might touch this code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 03:17:09 +02:00
|
|
|
test_eval_ "$1"
|
2010-05-06 10:41:10 +02:00
|
|
|
eval_ret=$?
|
2011-06-27 20:02:22 +02:00
|
|
|
|
|
|
|
if test -z "$immediate" || test $eval_ret = 0 || test -n "$expecting_failure"
|
|
|
|
then
|
test: cope better with use of return for errors
In olden times, tests would quietly exit the script when they failed
at an inconvenient moment, which was a little disconcerting.
Therefore v0.99.5~24^2~4 (Trapping exit in tests, using return for
errors, 2005-08-10) switched to an idiom of using "return" instead,
wrapping evaluation of test code in a function to make that safe:
test_run_ () {
eval >&3 2>&4 "$1"
eval_ret="$?"
return 0
}
Years later, the implementation of test_when_finished (v1.7.1.1~95,
2010-05-02) and v1.7.2-rc2~1^2~13 (test-lib: output a newline before
"ok" under a TAP harness, 2010-06-24) took advantage of test_run_ as a
place to put code shared by all test assertion functions, without
paying attention to the function's former purpose:
test_run_ () {
...
eval >&3 2>&4 "$1"
eval_ret=$?
if should run cleanup
then
eval >&3 2>&4 "$test_cleanup"
fi
if TAP format requires a newline here
then
echo
fi
return 0
}
That means cleanup commands and the newline to put TAP output at
column 0 are skipped when tests use "return" to fail early. Fix it by
introducing a test_eval_ function to catch the "return", with a
comment explaining the new function's purpose for the next person who
might touch this code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 03:17:09 +02:00
|
|
|
test_eval_ "$test_cleanup"
|
2011-06-27 20:02:22 +02:00
|
|
|
fi
|
test-lib: output a newline before "ok" under a TAP harness
Some tests in the testsuite will emit a line that doesn't end with a
newline, right before we're about to output "ok" or "not ok". This
breaks the TAP output with "Tests out of sequence" errors since a TAP
harness can't understand this:
ok 1 - A test
[some output here]ok 2 - Another test
ok 3 - Yet another test
Work around it by emitting an empty line before we're about to say
"ok" or "not ok", but only if we're running under --verbose and
HARNESS_ACTIVE=1 is set, which'll only be the case when running under
a harnesses like prove(1).
I think it's better to do this than fix each tests by adding `&& echo'
everywhere. More tests might be added that break TAP in the future,
and a human isn't going to look at the extra whitespace, since
HARNESS_ACTIVE=1 always means a harness is reading it.
The tests that had issues were:
t1007, t3410, t3413, t3409, t3414, t3415, t3416, t3412, t3404,
t5407, t7402, t7003, t9001
With this workaround the entire test suite runs without errors under:
prove -j 10 ./t[0-9]*.sh :: --verbose
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 19:44:47 +02:00
|
|
|
if test "$verbose" = "t" && test -n "$HARNESS_ACTIVE"; then
|
|
|
|
echo ""
|
|
|
|
fi
|
2011-08-08 03:15:34 +02:00
|
|
|
return "$eval_ret"
|
2005-08-11 05:56:21 +02:00
|
|
|
}
|
|
|
|
|
2006-12-29 02:58:00 +01:00
|
|
|
test_skip () {
|
2009-02-05 21:20:56 +01:00
|
|
|
test_count=$(($test_count+1))
|
2006-12-29 02:58:00 +01:00
|
|
|
to_skip=
|
|
|
|
for skp in $GIT_SKIP_TESTS
|
|
|
|
do
|
2009-02-05 21:20:56 +01:00
|
|
|
case $this_test.$test_count in
|
2006-12-29 02:58:00 +01:00
|
|
|
$skp)
|
|
|
|
to_skip=t
|
2010-07-12 12:32:18 +02:00
|
|
|
break
|
2006-12-29 02:58:00 +01:00
|
|
|
esac
|
|
|
|
done
|
2010-10-16 20:36:58 +02:00
|
|
|
if test -z "$to_skip" && test -n "$test_prereq" &&
|
|
|
|
! test_have_prereq "$test_prereq"
|
2009-03-01 21:04:46 +01:00
|
|
|
then
|
|
|
|
to_skip=t
|
|
|
|
fi
|
2006-12-29 02:58:00 +01:00
|
|
|
case "$to_skip" in
|
|
|
|
t)
|
2010-08-24 09:34:10 +02:00
|
|
|
of_prereq=
|
2010-10-16 20:36:58 +02:00
|
|
|
if test "$missing_prereq" != "$test_prereq"
|
2010-08-24 09:34:10 +02:00
|
|
|
then
|
2010-10-16 20:36:58 +02:00
|
|
|
of_prereq=" of $test_prereq"
|
2010-08-24 09:34:10 +02:00
|
|
|
fi
|
|
|
|
|
2007-10-24 22:03:38 +02:00
|
|
|
say_color skip >&3 "skipping test: $@"
|
2010-08-24 09:34:10 +02:00
|
|
|
say_color skip "ok $test_count # skip $1 (missing $missing_prereq${of_prereq})"
|
2006-12-29 02:58:00 +01:00
|
|
|
: true
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
false
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2005-05-14 07:50:32 +02:00
|
|
|
test_expect_failure () {
|
2010-10-16 20:36:58 +02:00
|
|
|
test "$#" = 3 && { test_prereq=$1; shift; } || test_prereq=
|
2005-08-11 07:53:27 +02:00
|
|
|
test "$#" = 2 ||
|
2009-03-01 21:04:46 +01:00
|
|
|
error "bug in the test script: not 2 or 3 parameters to test-expect-failure"
|
2010-10-16 20:36:58 +02:00
|
|
|
export test_prereq
|
2006-12-29 02:58:00 +01:00
|
|
|
if ! test_skip "$@"
|
2005-05-14 07:50:32 +02:00
|
|
|
then
|
2008-02-01 10:50:53 +01:00
|
|
|
say >&3 "checking known breakage: $2"
|
2011-08-08 03:15:34 +02:00
|
|
|
if test_run_ "$2" expecting_failure
|
2006-12-29 02:58:00 +01:00
|
|
|
then
|
2008-02-01 10:50:53 +01:00
|
|
|
test_known_broken_ok_ "$1"
|
2006-12-29 02:58:00 +01:00
|
|
|
else
|
2009-06-01 14:14:41 +02:00
|
|
|
test_known_broken_failure_ "$1"
|
2006-12-29 02:58:00 +01:00
|
|
|
fi
|
2005-05-14 07:50:32 +02:00
|
|
|
fi
|
2006-10-07 21:27:46 +02:00
|
|
|
echo >&3 ""
|
2005-05-14 07:50:32 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success () {
|
2010-10-16 20:36:58 +02:00
|
|
|
test "$#" = 3 && { test_prereq=$1; shift; } || test_prereq=
|
2005-08-11 07:53:27 +02:00
|
|
|
test "$#" = 2 ||
|
2009-03-01 21:04:46 +01:00
|
|
|
error "bug in the test script: not 2 or 3 parameters to test-expect-success"
|
2010-10-16 20:36:58 +02:00
|
|
|
export test_prereq
|
2006-12-29 02:58:00 +01:00
|
|
|
if ! test_skip "$@"
|
2005-05-14 07:50:32 +02:00
|
|
|
then
|
2006-12-29 02:58:00 +01:00
|
|
|
say >&3 "expecting success: $2"
|
2011-08-08 03:15:34 +02:00
|
|
|
if test_run_ "$2"
|
2006-12-29 02:58:00 +01:00
|
|
|
then
|
|
|
|
test_ok_ "$1"
|
|
|
|
else
|
|
|
|
test_failure_ "$@"
|
|
|
|
fi
|
2005-05-14 07:50:32 +02:00
|
|
|
fi
|
2006-10-07 21:27:46 +02:00
|
|
|
echo >&3 ""
|
2005-05-14 07:50:32 +02:00
|
|
|
}
|
|
|
|
|
2008-06-19 20:18:03 +02:00
|
|
|
# test_external runs external test scripts that provide continuous
|
|
|
|
# test output about their progress, and succeeds/fails on
|
|
|
|
# zero/non-zero exit code. It outputs the test output on stdout even
|
2010-06-24 19:44:46 +02:00
|
|
|
# in non-verbose mode, and announces the external script with "# run
|
2008-06-19 20:18:03 +02:00
|
|
|
# <n>: ..." before running it. When providing relative paths, keep in
|
|
|
|
# mind that all scripts run in "trash directory".
|
|
|
|
# Usage: test_external description command arguments...
|
|
|
|
# Example: test_external 'Perl API' perl ../path/to/test.pl
|
|
|
|
test_external () {
|
2010-10-16 20:36:58 +02:00
|
|
|
test "$#" = 4 && { test_prereq=$1; shift; } || test_prereq=
|
2009-03-01 21:04:46 +01:00
|
|
|
test "$#" = 3 ||
|
|
|
|
error >&5 "bug in the test script: not 3 or 4 parameters to test_external"
|
2008-06-19 20:18:03 +02:00
|
|
|
descr="$1"
|
|
|
|
shift
|
2010-10-16 20:36:58 +02:00
|
|
|
export test_prereq
|
2008-06-19 20:18:03 +02:00
|
|
|
if ! test_skip "$descr" "$@"
|
|
|
|
then
|
|
|
|
# Announce the script to reduce confusion about the
|
|
|
|
# test output that follows.
|
2010-06-24 19:44:46 +02:00
|
|
|
say_color "" "# run $test_count: $descr ($*)"
|
2010-04-24 15:50:09 +02:00
|
|
|
# Export TEST_DIRECTORY, TRASH_DIRECTORY and GIT_TEST_LONG
|
|
|
|
# to be able to use them in script
|
|
|
|
export TEST_DIRECTORY TRASH_DIRECTORY GIT_TEST_LONG
|
2008-06-19 20:18:03 +02:00
|
|
|
# Run command; redirect its stderr to &4 as in
|
|
|
|
# test_run_, but keep its stdout on our stdout even in
|
|
|
|
# non-verbose mode.
|
|
|
|
"$@" 2>&4
|
|
|
|
if [ "$?" = 0 ]
|
|
|
|
then
|
2010-06-24 19:44:46 +02:00
|
|
|
if test $test_external_has_tap -eq 0; then
|
|
|
|
test_ok_ "$descr"
|
|
|
|
else
|
|
|
|
say_color "" "# test_external test $descr was ok"
|
|
|
|
test_success=$(($test_success + 1))
|
|
|
|
fi
|
2008-06-19 20:18:03 +02:00
|
|
|
else
|
2010-06-24 19:44:46 +02:00
|
|
|
if test $test_external_has_tap -eq 0; then
|
|
|
|
test_failure_ "$descr" "$@"
|
|
|
|
else
|
|
|
|
say_color error "# test_external test $descr failed: $@"
|
|
|
|
test_failure=$(($test_failure + 1))
|
|
|
|
fi
|
2008-06-19 20:18:03 +02:00
|
|
|
fi
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
# Like test_external, but in addition tests that the command generated
|
|
|
|
# no output on stderr.
|
|
|
|
test_external_without_stderr () {
|
|
|
|
# The temporary file has no (and must have no) security
|
|
|
|
# implications.
|
2011-04-29 14:30:30 +02:00
|
|
|
tmp=${TMPDIR:-/tmp}
|
2008-06-19 20:18:03 +02:00
|
|
|
stderr="$tmp/git-external-stderr.$$.tmp"
|
|
|
|
test_external "$@" 4> "$stderr"
|
|
|
|
[ -f "$stderr" ] || error "Internal error: $stderr disappeared."
|
|
|
|
descr="no stderr: $1"
|
|
|
|
shift
|
2010-06-24 19:44:46 +02:00
|
|
|
say >&3 "# expecting no stderr from previous command"
|
2008-06-19 20:18:03 +02:00
|
|
|
if [ ! -s "$stderr" ]; then
|
|
|
|
rm "$stderr"
|
2010-06-24 19:44:46 +02:00
|
|
|
|
|
|
|
if test $test_external_has_tap -eq 0; then
|
|
|
|
test_ok_ "$descr"
|
|
|
|
else
|
|
|
|
say_color "" "# test_external_without_stderr test $descr was ok"
|
|
|
|
test_success=$(($test_success + 1))
|
|
|
|
fi
|
2008-06-19 20:18:03 +02:00
|
|
|
else
|
|
|
|
if [ "$verbose" = t ]; then
|
2010-06-24 19:44:46 +02:00
|
|
|
output=`echo; echo "# Stderr is:"; cat "$stderr"`
|
2008-06-19 20:18:03 +02:00
|
|
|
else
|
|
|
|
output=
|
|
|
|
fi
|
|
|
|
# rm first in case test_failure exits.
|
|
|
|
rm "$stderr"
|
2010-06-24 19:44:46 +02:00
|
|
|
if test $test_external_has_tap -eq 0; then
|
|
|
|
test_failure_ "$descr" "$@" "$output"
|
|
|
|
else
|
|
|
|
say_color error "# test_external_without_stderr test $descr failed: $@: $output"
|
|
|
|
test_failure=$(($test_failure + 1))
|
|
|
|
fi
|
2008-06-19 20:18:03 +02:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2010-08-10 17:17:52 +02:00
|
|
|
# debugging-friendly alternatives to "test [-f|-d|-e]"
|
|
|
|
# The commands test the existence or non-existence of $1. $2 can be
|
|
|
|
# given to provide a more precise diagnosis.
|
|
|
|
test_path_is_file () {
|
|
|
|
if ! [ -f "$1" ]
|
|
|
|
then
|
|
|
|
echo "File $1 doesn't exist. $*"
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
test_path_is_dir () {
|
|
|
|
if ! [ -d "$1" ]
|
|
|
|
then
|
|
|
|
echo "Directory $1 doesn't exist. $*"
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
test_path_is_missing () {
|
|
|
|
if [ -e "$1" ]
|
|
|
|
then
|
|
|
|
echo "Path exists:"
|
|
|
|
ls -ld "$1"
|
|
|
|
if [ $# -ge 1 ]; then
|
|
|
|
echo "$*"
|
|
|
|
fi
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2010-10-31 08:33:50 +01:00
|
|
|
# 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
|
|
|
|
}
|
2010-08-10 17:17:52 +02:00
|
|
|
|
2008-02-28 22:09:30 +01:00
|
|
|
# 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:
|
|
|
|
#
|
|
|
|
# test_expect_success 'complain and die' '
|
|
|
|
# do something &&
|
|
|
|
# do something else &&
|
|
|
|
# test_must_fail git checkout ../outerspace
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# Writing this as "! git checkout ../outerspace" is wrong, because
|
|
|
|
# the failure could be due to a segv. We want a controlled failure.
|
|
|
|
|
|
|
|
test_must_fail () {
|
|
|
|
"$@"
|
2010-08-31 17:56:36 +02:00
|
|
|
exit_code=$?
|
|
|
|
if test $exit_code = 0; then
|
|
|
|
echo >&2 "test_must_fail: command succeeded: $*"
|
|
|
|
return 1
|
|
|
|
elif test $exit_code -gt 129 -a $exit_code -le 192; then
|
|
|
|
echo >&2 "test_must_fail: died by signal: $*"
|
|
|
|
return 1
|
2010-08-31 17:56:53 +02:00
|
|
|
elif test $exit_code = 127; then
|
|
|
|
echo >&2 "test_must_fail: command not found: $*"
|
|
|
|
return 1
|
2010-08-31 17:56:36 +02:00
|
|
|
fi
|
|
|
|
return 0
|
2008-02-28 22:09:30 +01:00
|
|
|
}
|
|
|
|
|
2010-04-15 02:38:07 +02:00
|
|
|
# Similar to test_must_fail, but tolerates success, too. This is
|
|
|
|
# meant to be used in contexts like:
|
|
|
|
#
|
|
|
|
# test_expect_success 'some command works without configuration' '
|
|
|
|
# test_might_fail git config --unset all.configuration &&
|
|
|
|
# do something
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# Writing "git config --unset all.configuration || :" would be wrong,
|
|
|
|
# because we want to notice if it fails due to segv.
|
|
|
|
|
|
|
|
test_might_fail () {
|
|
|
|
"$@"
|
2010-08-31 19:10:55 +02:00
|
|
|
exit_code=$?
|
|
|
|
if test $exit_code -gt 129 -a $exit_code -le 192; then
|
|
|
|
echo >&2 "test_might_fail: died by signal: $*"
|
|
|
|
return 1
|
2010-08-31 19:26:57 +02:00
|
|
|
elif test $exit_code = 127; then
|
|
|
|
echo >&2 "test_might_fail: command not found: $*"
|
|
|
|
return 1
|
2010-08-31 19:10:55 +02:00
|
|
|
fi
|
|
|
|
return 0
|
2010-04-15 02:38:07 +02:00
|
|
|
}
|
|
|
|
|
2010-10-03 21:59:59 +02:00
|
|
|
# Similar to test_must_fail and test_might_fail, but check that a
|
|
|
|
# given command exited with a given exit code. Meant to be used as:
|
|
|
|
#
|
|
|
|
# test_expect_success 'Merge with d/f conflicts' '
|
|
|
|
# test_expect_code 1 git merge "merge msg" B master
|
|
|
|
# '
|
|
|
|
|
|
|
|
test_expect_code () {
|
|
|
|
want_code=$1
|
|
|
|
shift
|
|
|
|
"$@"
|
|
|
|
exit_code=$?
|
|
|
|
if test $exit_code = $want_code
|
|
|
|
then
|
|
|
|
return 0
|
|
|
|
fi
|
2011-05-21 21:40:32 +02:00
|
|
|
|
|
|
|
echo >&2 "test_expect_code: command exited with $exit_code, we wanted $want_code $*"
|
|
|
|
return 1
|
2010-10-03 21:59:59 +02:00
|
|
|
}
|
|
|
|
|
2008-03-12 22:36:36 +01:00
|
|
|
# test_cmp is a helper function to compare actual and expected output.
|
|
|
|
# You can use it like:
|
|
|
|
#
|
|
|
|
# test_expect_success 'foo works' '
|
|
|
|
# echo expected >expected &&
|
|
|
|
# foo >actual &&
|
|
|
|
# test_cmp expected actual
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# This could be written as either "cmp" or "diff -u", but:
|
|
|
|
# - cmp's output is not nearly as easy to read as diff -u
|
|
|
|
# - not all diff versions understand "-u"
|
|
|
|
|
|
|
|
test_cmp() {
|
|
|
|
$GIT_TEST_CMP "$@"
|
|
|
|
}
|
|
|
|
|
test-lib: Let tests specify commands to be run at end of test
Certain actions can imply that if the test fails early, recovery from
within other tests is too much to expect:
- creating unwritable directories, like the EACCESS test in t0001-init
- setting unusual configuration, like user.signingkey in t7004-tag
- crashing and leaving the index lock held, like t3600-rm once did
Some test scripts work around this by running cleanup actions outside
the supervision of the test harness, with the unfortunate consequence
that those commands are not appropriately echoed and their output not
suppressed. Others explicitly save exit status, clean up, and then
reset the exit status within the tests, which has excellent behavior
but makes the tests hard to read. Still others ignore the problem.
Allow tests a fourth option: by calling this function, tests can
stack up commands they would like to be run to clean up.
Commands passed to test_when_finished during a test are
unconditionally run in the test environment immediately before the
test is completed, in last-in-first-out order. If some cleanup
command fails, then the other cleanup commands are still run before
the failure is reported and the test script allowed to continue.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-02 10:53:41 +02:00
|
|
|
# This function can be used to schedule some commands to be run
|
|
|
|
# unconditionally at the end of the test to restore sanity:
|
|
|
|
#
|
|
|
|
# test_expect_success 'test core.capslock' '
|
|
|
|
# git config core.capslock true &&
|
|
|
|
# test_when_finished "git config --unset core.capslock" &&
|
|
|
|
# hello world
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# That would be roughly equivalent to
|
|
|
|
#
|
|
|
|
# test_expect_success 'test core.capslock' '
|
|
|
|
# git config core.capslock true &&
|
|
|
|
# hello world
|
|
|
|
# git config --unset core.capslock
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# except that the greeting and config --unset must both succeed for
|
|
|
|
# the test to pass.
|
2011-06-27 20:02:22 +02:00
|
|
|
#
|
|
|
|
# Note that under --immediate mode, no clean-up is done to help diagnose
|
|
|
|
# what went wrong.
|
test-lib: Let tests specify commands to be run at end of test
Certain actions can imply that if the test fails early, recovery from
within other tests is too much to expect:
- creating unwritable directories, like the EACCESS test in t0001-init
- setting unusual configuration, like user.signingkey in t7004-tag
- crashing and leaving the index lock held, like t3600-rm once did
Some test scripts work around this by running cleanup actions outside
the supervision of the test harness, with the unfortunate consequence
that those commands are not appropriately echoed and their output not
suppressed. Others explicitly save exit status, clean up, and then
reset the exit status within the tests, which has excellent behavior
but makes the tests hard to read. Still others ignore the problem.
Allow tests a fourth option: by calling this function, tests can
stack up commands they would like to be run to clean up.
Commands passed to test_when_finished during a test are
unconditionally run in the test environment immediately before the
test is completed, in last-in-first-out order. If some cleanup
command fails, then the other cleanup commands are still run before
the failure is reported and the test script allowed to continue.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-02 10:53:41 +02:00
|
|
|
|
|
|
|
test_when_finished () {
|
2010-05-06 10:41:10 +02:00
|
|
|
test_cleanup="{ $*
|
|
|
|
} && (exit \"\$eval_ret\"); eval_ret=\$?; $test_cleanup"
|
test-lib: Let tests specify commands to be run at end of test
Certain actions can imply that if the test fails early, recovery from
within other tests is too much to expect:
- creating unwritable directories, like the EACCESS test in t0001-init
- setting unusual configuration, like user.signingkey in t7004-tag
- crashing and leaving the index lock held, like t3600-rm once did
Some test scripts work around this by running cleanup actions outside
the supervision of the test harness, with the unfortunate consequence
that those commands are not appropriately echoed and their output not
suppressed. Others explicitly save exit status, clean up, and then
reset the exit status within the tests, which has excellent behavior
but makes the tests hard to read. Still others ignore the problem.
Allow tests a fourth option: by calling this function, tests can
stack up commands they would like to be run to clean up.
Commands passed to test_when_finished during a test are
unconditionally run in the test environment immediately before the
test is completed, in last-in-first-out order. If some cleanup
command fails, then the other cleanup commands are still run before
the failure is reported and the test script allowed to continue.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-02 10:53:41 +02:00
|
|
|
}
|
|
|
|
|
2008-01-31 22:59:11 +01:00
|
|
|
# Most tests can use the created repository, but some may need to create more.
|
2006-02-17 22:33:26 +01:00
|
|
|
# Usage: test_create_repo <directory>
|
|
|
|
test_create_repo () {
|
|
|
|
test "$#" = 1 ||
|
|
|
|
error "bug in the test script: not 1 parameter to test-create-repo"
|
|
|
|
repo="$1"
|
2008-08-08 11:26:28 +02:00
|
|
|
mkdir -p "$repo"
|
2010-08-30 14:00:42 +02:00
|
|
|
(
|
|
|
|
cd "$repo" || error "Cannot setup test environment"
|
|
|
|
"$GIT_EXEC_PATH/git-init" "--template=$GIT_BUILD_DIR/templates/blt/" >&3 2>&4 ||
|
|
|
|
error "cannot run git init -- have you built things yet?"
|
|
|
|
mv .git/hooks .git/hooks-disabled
|
|
|
|
) || exit
|
2006-02-17 22:33:26 +01:00
|
|
|
}
|
2007-06-07 09:04:01 +02:00
|
|
|
|
2005-05-14 07:50:32 +02:00
|
|
|
test_done () {
|
2009-06-01 14:14:41 +02:00
|
|
|
GIT_EXIT_OK=t
|
2008-06-08 16:04:33 +02:00
|
|
|
|
2010-08-11 21:37:31 +02:00
|
|
|
if test -z "$HARNESS_ACTIVE"; then
|
|
|
|
test_results_dir="$TEST_DIRECTORY/test-results"
|
|
|
|
mkdir -p "$test_results_dir"
|
|
|
|
test_results_path="$test_results_dir/${0%.sh}-$$.counts"
|
|
|
|
|
2011-04-29 14:30:30 +02:00
|
|
|
cat >>"$test_results_path" <<-EOF
|
|
|
|
total $test_count
|
|
|
|
success $test_success
|
|
|
|
fixed $test_fixed
|
|
|
|
broken $test_broken
|
|
|
|
failed $test_failure
|
|
|
|
|
|
|
|
EOF
|
2010-08-11 21:37:31 +02:00
|
|
|
fi
|
2008-02-01 10:50:53 +01:00
|
|
|
|
|
|
|
if test "$test_fixed" != 0
|
|
|
|
then
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
say_color pass "# fixed $test_fixed known breakage(s)"
|
2008-02-01 10:50:53 +01:00
|
|
|
fi
|
|
|
|
if test "$test_broken" != 0
|
|
|
|
then
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
say_color error "# still have $test_broken known breakage(s)"
|
2008-02-03 09:23:02 +01:00
|
|
|
msg="remaining $(($test_count-$test_broken)) test(s)"
|
|
|
|
else
|
|
|
|
msg="$test_count test(s)"
|
2008-02-01 10:50:53 +01:00
|
|
|
fi
|
2005-05-14 07:50:32 +02:00
|
|
|
case "$test_failure" in
|
2005-12-10 02:32:18 +01:00
|
|
|
0)
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
# Maybe print SKIP message
|
|
|
|
[ -z "$skip_all" ] || skip_all=" # SKIP $skip_all"
|
|
|
|
|
2010-06-24 19:44:46 +02:00
|
|
|
if test $test_external_has_tap -eq 0; then
|
|
|
|
say_color pass "# passed all $msg"
|
|
|
|
say "1..$test_count$skip_all"
|
|
|
|
fi
|
Enable parallel tests
On multiprocessor machines, or with I/O heavy tests (that leave the
CPU waiting a lot), it makes sense to parallelize the tests.
However, care has to be taken that the different jobs use different
trash directories.
This commit does so, by creating the trash directories with a suffix
that is unique with regard to the test, as it is the test's base name.
Further, the trash directory is removed in the test itself if
everything went fine, so that the trash directories do not
pile up only to be removed at the very end.
If a test failed, the trash directory is not removed. Chances are
that the exact error message is lost in the clutter, but you can still
see what test failed from the name of the trash directory, and repeat
the test (without -j).
If all was good, you will see the aggregated results.
Suggestions to simplify this commit came from Junio and René.
There still is an issue with tests that want to run a server process and
listen to a fixed port (http and svn) --- they cannot run in parallel but
this patch does not address this issue.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-08 13:08:37 +02:00
|
|
|
|
|
|
|
test -d "$remove_trash" &&
|
|
|
|
cd "$(dirname "$remove_trash")" &&
|
|
|
|
rm -rf "$(basename "$remove_trash")"
|
|
|
|
|
2005-05-14 07:50:32 +02:00
|
|
|
exit 0 ;;
|
|
|
|
|
|
|
|
*)
|
2010-06-24 19:44:46 +02:00
|
|
|
if test $test_external_has_tap -eq 0; then
|
|
|
|
say_color error "# failed $test_failure among $msg"
|
|
|
|
say "1..$test_count"
|
|
|
|
fi
|
test-lib: Adjust output to be valid TAP format
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24 23:52:12 +02:00
|
|
|
|
2005-05-14 07:50:32 +02:00
|
|
|
exit 1 ;;
|
|
|
|
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
|
|
|
# Test the binaries we have just built. The tests are kept in
|
2008-06-14 20:14:12 +02:00
|
|
|
# t/ subdirectory and are run in 'trash directory' subdirectory.
|
2010-08-19 18:08:11 +02:00
|
|
|
if test -z "$TEST_DIRECTORY"
|
|
|
|
then
|
|
|
|
# We allow tests to override this, in case they want to run tests
|
|
|
|
# outside of t/, e.g. for running tests on the test library
|
|
|
|
# itself.
|
|
|
|
TEST_DIRECTORY=$(pwd)
|
|
|
|
fi
|
2010-08-19 18:08:10 +02:00
|
|
|
GIT_BUILD_DIR="$TEST_DIRECTORY"/..
|
|
|
|
|
2009-12-03 06:14:06 +01:00
|
|
|
if test -n "$valgrind"
|
2009-02-04 00:25:59 +01:00
|
|
|
then
|
|
|
|
make_symlink () {
|
|
|
|
test -h "$2" &&
|
|
|
|
test "$1" = "$(readlink "$2")" || {
|
|
|
|
# be super paranoid
|
|
|
|
if mkdir "$2".lock
|
|
|
|
then
|
|
|
|
rm -f "$2" &&
|
|
|
|
ln -s "$1" "$2" &&
|
|
|
|
rm -r "$2".lock
|
|
|
|
else
|
|
|
|
while test -d "$2".lock
|
|
|
|
do
|
|
|
|
say "Waiting for lock on $2."
|
|
|
|
sleep 1
|
|
|
|
done
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
make_valgrind_symlink () {
|
2011-06-17 22:36:32 +02:00
|
|
|
# handle only executables, unless they are shell libraries that
|
|
|
|
# need to be in the exec-path. We will just use "#!" as a
|
|
|
|
# guess for a shell-script, since we have no idea what the user
|
|
|
|
# may have configured as the shell path.
|
|
|
|
test -x "$1" ||
|
|
|
|
test "#!" = "$(head -c 2 <"$1")" ||
|
|
|
|
return;
|
2009-02-04 00:25:59 +01:00
|
|
|
|
|
|
|
base=$(basename "$1")
|
2010-08-19 18:08:10 +02:00
|
|
|
symlink_target=$GIT_BUILD_DIR/$base
|
2009-02-04 00:25:59 +01:00
|
|
|
# do not override scripts
|
|
|
|
if test -x "$symlink_target" &&
|
|
|
|
test ! -d "$symlink_target" &&
|
|
|
|
test "#!" != "$(head -c 2 < "$symlink_target")"
|
|
|
|
then
|
|
|
|
symlink_target=../valgrind.sh
|
|
|
|
fi
|
2009-02-04 00:26:08 +01:00
|
|
|
case "$base" in
|
|
|
|
*.sh|*.perl)
|
|
|
|
symlink_target=../unprocessed-script
|
|
|
|
esac
|
2009-02-04 00:25:59 +01:00
|
|
|
# create the link, or replace it if it is out of date
|
|
|
|
make_symlink "$symlink_target" "$GIT_VALGRIND/bin/$base" || exit
|
|
|
|
}
|
|
|
|
|
|
|
|
# override all git executables in TEST_DIRECTORY/..
|
|
|
|
GIT_VALGRIND=$TEST_DIRECTORY/valgrind
|
|
|
|
mkdir -p "$GIT_VALGRIND"/bin
|
2010-08-19 18:08:10 +02:00
|
|
|
for file in $GIT_BUILD_DIR/git* $GIT_BUILD_DIR/test-*
|
2009-02-04 00:25:59 +01:00
|
|
|
do
|
|
|
|
make_valgrind_symlink $file
|
|
|
|
done
|
2011-08-30 02:47:36 +02:00
|
|
|
# special-case the mergetools loadables
|
|
|
|
make_symlink "$GIT_BUILD_DIR"/mergetools "$GIT_VALGRIND/bin/mergetools"
|
2009-02-04 00:26:08 +01:00
|
|
|
OLDIFS=$IFS
|
|
|
|
IFS=:
|
|
|
|
for path in $PATH
|
|
|
|
do
|
|
|
|
ls "$path"/git-* 2> /dev/null |
|
|
|
|
while read file
|
|
|
|
do
|
|
|
|
make_valgrind_symlink "$file"
|
|
|
|
done
|
|
|
|
done
|
|
|
|
IFS=$OLDIFS
|
2009-02-04 00:25:59 +01:00
|
|
|
PATH=$GIT_VALGRIND/bin:$PATH
|
|
|
|
GIT_EXEC_PATH=$GIT_VALGRIND/bin
|
|
|
|
export GIT_VALGRIND
|
2009-12-03 06:14:06 +01:00
|
|
|
elif test -n "$GIT_TEST_INSTALLED" ; then
|
|
|
|
GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path) ||
|
|
|
|
error "Cannot run git from $GIT_TEST_INSTALLED."
|
2010-08-19 18:08:10 +02:00
|
|
|
PATH=$GIT_TEST_INSTALLED:$GIT_BUILD_DIR:$PATH
|
2009-12-03 06:14:06 +01:00
|
|
|
GIT_EXEC_PATH=${GIT_TEST_EXEC_PATH:-$GIT_EXEC_PATH}
|
|
|
|
else # normal case, use ../bin-wrappers only unless $with_dashes:
|
2010-08-19 18:08:10 +02:00
|
|
|
git_bin_dir="$GIT_BUILD_DIR/bin-wrappers"
|
2009-12-03 06:14:06 +01:00
|
|
|
if ! test -x "$git_bin_dir/git" ; then
|
|
|
|
if test -z "$with_dashes" ; then
|
|
|
|
say "$git_bin_dir/git is not executable; using GIT_EXEC_PATH"
|
|
|
|
fi
|
|
|
|
with_dashes=t
|
|
|
|
fi
|
|
|
|
PATH="$git_bin_dir:$PATH"
|
2010-08-19 18:08:10 +02:00
|
|
|
GIT_EXEC_PATH=$GIT_BUILD_DIR
|
2009-12-03 06:14:06 +01:00
|
|
|
if test -n "$with_dashes" ; then
|
2010-08-19 18:08:10 +02:00
|
|
|
PATH="$GIT_BUILD_DIR:$PATH"
|
2009-12-03 06:14:06 +01:00
|
|
|
fi
|
2009-02-04 00:25:59 +01:00
|
|
|
fi
|
2010-08-19 18:08:10 +02:00
|
|
|
GIT_TEMPLATE_DIR="$GIT_BUILD_DIR"/templates/blt
|
2008-02-06 11:11:53 +01:00
|
|
|
unset GIT_CONFIG
|
|
|
|
GIT_CONFIG_NOSYSTEM=1
|
2011-03-15 10:05:10 +01:00
|
|
|
GIT_ATTR_NOSYSTEM=1
|
2011-03-15 10:04:49 +01:00
|
|
|
export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_ATTR_NOSYSTEM
|
2005-12-08 06:52:28 +01:00
|
|
|
|
2010-08-19 18:08:09 +02:00
|
|
|
. "$GIT_BUILD_DIR"/GIT-BUILD-OPTIONS
|
2009-12-07 06:32:50 +01:00
|
|
|
|
2010-06-11 18:40:25 +02:00
|
|
|
if test -z "$GIT_TEST_CMP"
|
|
|
|
then
|
|
|
|
if test -n "$GIT_TEST_CMP_USE_COPIED_CONTEXT"
|
|
|
|
then
|
|
|
|
GIT_TEST_CMP="$DIFF -c"
|
|
|
|
else
|
|
|
|
GIT_TEST_CMP="$DIFF -u"
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
2010-08-19 18:08:10 +02:00
|
|
|
GITPERLLIB="$GIT_BUILD_DIR"/perl/blib/lib:"$GIT_BUILD_DIR"/perl/blib/arch/auto/Git
|
2006-07-03 23:16:32 +02:00
|
|
|
export GITPERLLIB
|
2010-08-19 18:08:10 +02:00
|
|
|
test -d "$GIT_BUILD_DIR"/templates/blt || {
|
2005-12-11 05:55:32 +01:00
|
|
|
error "You haven't built things yet, have you?"
|
|
|
|
}
|
2005-05-14 07:50:32 +02:00
|
|
|
|
2009-12-07 06:32:50 +01:00
|
|
|
if test -z "$GIT_TEST_INSTALLED" && test -z "$NO_PYTHON"
|
2009-11-18 02:42:32 +01:00
|
|
|
then
|
2010-08-19 18:08:10 +02:00
|
|
|
GITPYTHONLIB="$GIT_BUILD_DIR/git_remote_helpers/build/lib"
|
2009-11-18 02:42:32 +01:00
|
|
|
export GITPYTHONLIB
|
2010-08-19 18:08:10 +02:00
|
|
|
test -d "$GIT_BUILD_DIR"/git_remote_helpers/build || {
|
2009-11-18 02:42:32 +01:00
|
|
|
error "You haven't built git_remote_helpers yet, have you?"
|
|
|
|
}
|
|
|
|
fi
|
|
|
|
|
2010-08-19 18:08:10 +02:00
|
|
|
if ! test -x "$GIT_BUILD_DIR"/test-chmtime; then
|
2007-02-25 01:59:52 +01:00
|
|
|
echo >&2 'You need to build test-chmtime:'
|
|
|
|
echo >&2 'Run "make test-chmtime" in the source (toplevel) directory'
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2005-05-14 07:50:32 +02:00
|
|
|
# Test repository
|
Enable parallel tests
On multiprocessor machines, or with I/O heavy tests (that leave the
CPU waiting a lot), it makes sense to parallelize the tests.
However, care has to be taken that the different jobs use different
trash directories.
This commit does so, by creating the trash directories with a suffix
that is unique with regard to the test, as it is the test's base name.
Further, the trash directory is removed in the test itself if
everything went fine, so that the trash directories do not
pile up only to be removed at the very end.
If a test failed, the trash directory is not removed. Chances are
that the exact error message is lost in the clutter, but you can still
see what test failed from the name of the trash directory, and repeat
the test (without -j).
If all was good, you will see the aggregated results.
Suggestions to simplify this commit came from Junio and René.
There still is an issue with tests that want to run a server process and
listen to a fixed port (http and svn) --- they cannot run in parallel but
this patch does not address this issue.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-08 13:08:37 +02:00
|
|
|
test="trash directory.$(basename "$0" .sh)"
|
2009-08-09 10:39:45 +02:00
|
|
|
test -n "$root" && test="$root/$test"
|
|
|
|
case "$test" in
|
|
|
|
/*) TRASH_DIRECTORY="$test" ;;
|
|
|
|
*) TRASH_DIRECTORY="$TEST_DIRECTORY/$test" ;;
|
|
|
|
esac
|
2009-08-09 10:38:11 +02:00
|
|
|
test ! -z "$debug" || remove_trash=$TRASH_DIRECTORY
|
2008-03-19 05:58:01 +01:00
|
|
|
rm -fr "$test" || {
|
2009-06-01 14:14:41 +02:00
|
|
|
GIT_EXIT_OK=t
|
2008-03-19 05:58:01 +01:00
|
|
|
echo >&5 "FATAL: Cannot prepare test area"
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
|
2011-03-26 19:46:34 +01:00
|
|
|
HOME="$TRASH_DIRECTORY"
|
|
|
|
export HOME
|
|
|
|
|
2008-05-04 07:38:00 +02:00
|
|
|
test_create_repo "$test"
|
2008-05-31 23:11:21 +02:00
|
|
|
# Use -P to resolve symlinks in our working directory so that the cwd
|
|
|
|
# in subprocesses like git equals our $PWD (for pathname comparisons).
|
|
|
|
cd -P "$test" || exit 1
|
2006-12-29 02:58:00 +01:00
|
|
|
|
2009-02-05 20:59:27 +01:00
|
|
|
this_test=${0##*/}
|
|
|
|
this_test=${this_test%%-*}
|
2006-12-29 02:58:00 +01:00
|
|
|
for skp in $GIT_SKIP_TESTS
|
|
|
|
do
|
2010-07-12 12:32:18 +02:00
|
|
|
case "$this_test" in
|
|
|
|
$skp)
|
2007-10-24 22:03:38 +02:00
|
|
|
say_color skip >&3 "skipping test $this_test altogether"
|
2010-07-12 12:33:49 +02:00
|
|
|
skip_all="skip all tests in $this_test"
|
2006-12-29 02:58:00 +01:00
|
|
|
test_done
|
|
|
|
esac
|
|
|
|
done
|
2009-03-11 21:17:26 +01:00
|
|
|
|
2009-08-29 00:32:41 +02:00
|
|
|
# Provide an implementation of the 'yes' utility
|
|
|
|
yes () {
|
|
|
|
if test $# = 0
|
|
|
|
then
|
|
|
|
y=y
|
|
|
|
else
|
|
|
|
y="$*"
|
|
|
|
fi
|
|
|
|
|
|
|
|
while echo "$y"
|
|
|
|
do
|
|
|
|
:
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
2009-03-11 21:17:26 +01:00
|
|
|
# Fix some commands on Windows
|
|
|
|
case $(uname -s) in
|
|
|
|
*MINGW*)
|
|
|
|
# Windows has its own (incompatible) sort and find
|
|
|
|
sort () {
|
|
|
|
/usr/bin/sort "$@"
|
|
|
|
}
|
|
|
|
find () {
|
|
|
|
/usr/bin/find "$@"
|
|
|
|
}
|
2009-03-14 22:21:27 +01:00
|
|
|
sum () {
|
|
|
|
md5sum "$@"
|
|
|
|
}
|
2009-03-13 23:35:24 +01:00
|
|
|
# git sees Windows-style pwd
|
|
|
|
pwd () {
|
|
|
|
builtin pwd -W
|
|
|
|
}
|
2009-03-13 22:55:27 +01:00
|
|
|
# no POSIX permissions
|
2009-03-13 23:00:15 +01:00
|
|
|
# backslashes in pathspec are converted to '/'
|
2009-03-25 13:21:15 +01:00
|
|
|
# exec does not inherit the PID
|
2010-09-12 11:37:24 +02:00
|
|
|
test_set_prereq MINGW
|
2010-12-14 19:32:12 +01:00
|
|
|
test_set_prereq SED_STRIPS_CR
|
|
|
|
;;
|
|
|
|
*CYGWIN*)
|
|
|
|
test_set_prereq POSIXPERM
|
|
|
|
test_set_prereq EXECKEEPSPID
|
|
|
|
test_set_prereq NOT_MINGW
|
|
|
|
test_set_prereq SED_STRIPS_CR
|
2009-03-13 22:55:27 +01:00
|
|
|
;;
|
|
|
|
*)
|
|
|
|
test_set_prereq POSIXPERM
|
2009-03-13 23:00:15 +01:00
|
|
|
test_set_prereq BSLASHPSPEC
|
2009-03-25 13:21:15 +01:00
|
|
|
test_set_prereq EXECKEEPSPID
|
2010-09-27 23:02:57 +02:00
|
|
|
test_set_prereq NOT_MINGW
|
2009-03-11 21:17:26 +01:00
|
|
|
;;
|
|
|
|
esac
|
2009-03-04 22:38:24 +01:00
|
|
|
|
2009-04-03 21:33:59 +02:00
|
|
|
test -z "$NO_PERL" && test_set_prereq PERL
|
2009-11-18 02:42:31 +01:00
|
|
|
test -z "$NO_PYTHON" && test_set_prereq PYTHON
|
2011-05-09 23:52:07 +02:00
|
|
|
test -n "$USE_LIBPCRE" && test_set_prereq LIBPCRE
|
i18n: add infrastructure for translating Git with gettext
Change the skeleton implementation of i18n in Git to one that can show
localized strings to users for our C, Shell and Perl programs using
either GNU libintl or the Solaris gettext implementation.
This new internationalization support is enabled by default. If
gettext isn't available, or if Git is compiled with
NO_GETTEXT=YesPlease, Git falls back on its current behavior of
showing interface messages in English. When using the autoconf script
we'll auto-detect if the gettext libraries are installed and act
appropriately.
This change is somewhat large because as well as adding a C, Shell and
Perl i18n interface we're adding a lot of tests for them, and for
those tests to work we need a skeleton PO file to actually test
translations. A minimal Icelandic translation is included for this
purpose. Icelandic includes multi-byte characters which makes it easy
to test various edge cases, and it's a language I happen to
understand.
The rest of the commit message goes into detail about various
sub-parts of this commit.
= Installation
Gettext .mo files will be installed and looked for in the standard
$(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
override that, but that's only intended to be used to test Git itself.
= Perl
Perl code that's to be localized should use the new Git::I18n
module. It imports a __ function into the caller's package by default.
Instead of using the high level Locale::TextDomain interface I've
opted to use the low-level (equivalent to the C interface)
Locale::Messages module, which Locale::TextDomain itself uses.
Locale::TextDomain does a lot of redundant work we don't need, and
some of it would potentially introduce bugs. It tries to set the
$TEXTDOMAIN based on package of the caller, and has its own
hardcoded paths where it'll search for messages.
I found it easier just to completely avoid it rather than try to
circumvent its behavior. In any case, this is an issue wholly
internal Git::I18N. Its guts can be changed later if that's deemed
necessary.
See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
a further elaboration on this topic.
= Shell
Shell code that's to be localized should use the git-sh-i18n
library. It's basically just a wrapper for the system's gettext.sh.
If gettext.sh isn't available we'll fall back on gettext(1) if it's
available. The latter is available without the former on Solaris,
which has its own non-GNU gettext implementation. We also need to
emulate eval_gettext() there.
If neither are present we'll use a dumb printf(1) fall-through
wrapper.
= About libcharset.h and langinfo.h
We use libcharset to query the character set of the current locale if
it's available. I.e. we'll use it instead of nl_langinfo if
HAVE_LIBCHARSET_H is set.
The GNU gettext manual recommends using langinfo.h's
nl_langinfo(CODESET) to acquire the current character set, but on
systems that have libcharset.h's locale_charset() using the latter is
either saner, or the only option on those systems.
GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
but MinGW and some others need to use libcharset.h's locale_charset()
instead.
=Credits
This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
did the initial Makefile / C work, and a lot of comments from the Git
mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
others.
[jc: squashed a small Makefile fix from Ramsay]
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-18 00:14:42 +01:00
|
|
|
test -z "$NO_GETTEXT" && test_set_prereq GETTEXT
|
2009-04-03 21:33:59 +02:00
|
|
|
|
2011-02-23 00:41:21 +01:00
|
|
|
# Can we rely on git's output in the C locale?
|
2011-02-23 00:41:22 +01:00
|
|
|
if test -n "$GETTEXT_POISON"
|
|
|
|
then
|
|
|
|
GIT_GETTEXT_POISON=YesPlease
|
|
|
|
export GIT_GETTEXT_POISON
|
i18n: add infrastructure for translating Git with gettext
Change the skeleton implementation of i18n in Git to one that can show
localized strings to users for our C, Shell and Perl programs using
either GNU libintl or the Solaris gettext implementation.
This new internationalization support is enabled by default. If
gettext isn't available, or if Git is compiled with
NO_GETTEXT=YesPlease, Git falls back on its current behavior of
showing interface messages in English. When using the autoconf script
we'll auto-detect if the gettext libraries are installed and act
appropriately.
This change is somewhat large because as well as adding a C, Shell and
Perl i18n interface we're adding a lot of tests for them, and for
those tests to work we need a skeleton PO file to actually test
translations. A minimal Icelandic translation is included for this
purpose. Icelandic includes multi-byte characters which makes it easy
to test various edge cases, and it's a language I happen to
understand.
The rest of the commit message goes into detail about various
sub-parts of this commit.
= Installation
Gettext .mo files will be installed and looked for in the standard
$(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
override that, but that's only intended to be used to test Git itself.
= Perl
Perl code that's to be localized should use the new Git::I18n
module. It imports a __ function into the caller's package by default.
Instead of using the high level Locale::TextDomain interface I've
opted to use the low-level (equivalent to the C interface)
Locale::Messages module, which Locale::TextDomain itself uses.
Locale::TextDomain does a lot of redundant work we don't need, and
some of it would potentially introduce bugs. It tries to set the
$TEXTDOMAIN based on package of the caller, and has its own
hardcoded paths where it'll search for messages.
I found it easier just to completely avoid it rather than try to
circumvent its behavior. In any case, this is an issue wholly
internal Git::I18N. Its guts can be changed later if that's deemed
necessary.
See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
a further elaboration on this topic.
= Shell
Shell code that's to be localized should use the git-sh-i18n
library. It's basically just a wrapper for the system's gettext.sh.
If gettext.sh isn't available we'll fall back on gettext(1) if it's
available. The latter is available without the former on Solaris,
which has its own non-GNU gettext implementation. We also need to
emulate eval_gettext() there.
If neither are present we'll use a dumb printf(1) fall-through
wrapper.
= About libcharset.h and langinfo.h
We use libcharset to query the character set of the current locale if
it's available. I.e. we'll use it instead of nl_langinfo if
HAVE_LIBCHARSET_H is set.
The GNU gettext manual recommends using langinfo.h's
nl_langinfo(CODESET) to acquire the current character set, but on
systems that have libcharset.h's locale_charset() using the latter is
either saner, or the only option on those systems.
GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
but MinGW and some others need to use libcharset.h's locale_charset()
instead.
=Credits
This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
did the initial Makefile / C work, and a lot of comments from the Git
mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
others.
[jc: squashed a small Makefile fix from Ramsay]
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-18 00:14:42 +01:00
|
|
|
test_set_prereq GETTEXT_POISON
|
2011-02-23 00:41:22 +01:00
|
|
|
else
|
|
|
|
test_set_prereq C_LOCALE_OUTPUT
|
|
|
|
fi
|
2011-02-23 00:41:21 +01:00
|
|
|
|
2011-04-12 20:23:23 +02:00
|
|
|
# Use this instead of test_cmp to compare files that contain expected and
|
|
|
|
# actual output from git commands that can be translated. When running
|
|
|
|
# under GETTEXT_POISON this pretends that the command produced expected
|
|
|
|
# results.
|
|
|
|
test_i18ncmp () {
|
|
|
|
test -n "$GETTEXT_POISON" || test_cmp "$@"
|
|
|
|
}
|
|
|
|
|
2011-04-13 00:57:08 +02:00
|
|
|
# Use this instead of "grep expected-string actual" to see if the
|
|
|
|
# output from a git command that can be translated either contains an
|
|
|
|
# expected string, or does not contain an unwanted one. When running
|
|
|
|
# under GETTEXT_POISON this pretends that the command produced expected
|
|
|
|
# results.
|
|
|
|
test_i18ngrep () {
|
|
|
|
if test -n "$GETTEXT_POISON"
|
|
|
|
then
|
|
|
|
: # pretend success
|
|
|
|
elif test "x!" = "x$1"
|
|
|
|
then
|
|
|
|
shift
|
|
|
|
! grep "$@"
|
|
|
|
else
|
|
|
|
grep "$@"
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2009-03-04 22:38:24 +01:00
|
|
|
# test whether the filesystem supports symbolic links
|
|
|
|
ln -s x y 2>/dev/null && test -h y 2>/dev/null && test_set_prereq SYMLINKS
|
|
|
|
rm -f y
|
2010-08-07 00:09:09 +02:00
|
|
|
|
|
|
|
# When the tests are run as root, permission tests will report that
|
|
|
|
# things are writable when they shouldn't be.
|
|
|
|
test -w / || test_set_prereq SANITY
|