delta/git.git/t/test-lib.sh, branch ao/path-use-xmalloc

test: allow skipping the remainder

2017-05-18T02:53:22+00:00

Because TAP output does not like to see the remainder of the test
getting skipped after running one or more tests, bf4b7219
("test-lib.sh: Add check for invalid use of 'skip_all' facility",
2012-09-01) made sure that test_done errors out when this happens.

Instead, loosen the check so that we only pretend that the rest of
the test script did not exist in such a case.  We'd lose a bit of
information (i.e. TAP does not notice that we are skipping some
tests), but not very much (i.e. TAP wasn't told how many tests are
skipped anyway).

This will allow inclusion of lib-httpd.sh in the middle of a test,
which will skip the remainder of the test scripts when tests that
involve web server are declined with GIT_TEST_HTTPD=false, for
example.

Acked-by: Ramsay Jones 
Signed-off-by: Junio C Hamano

Merge branch 'jc/lint-runaway-here-doc'

2017-03-27T17:59:25+00:00

The test framework learned to detect unterminated here documents.

* jc/lint-runaway-here-doc:
  tests: lint for run-away here-doc

tests: lint for run-away here-doc

2017-03-24T03:56:49+00:00

We found a few run-away here documents that are started with an
end-of-here-doc marker that is incorrectly spelled, e.g.

	git some command >actual &&
	cat <expect
	...
	EOF &&
	test_cmp expect actual

which ends up slurping the entire remainder of the script as if it
were the data.  Often the command that gets misused like this exits
without failure (e.g. "cat" in the above example), which makes the
command appear to work, without ever executing the remainder of the
test.

Piggy-back on the test that catches &&-chain breakage to detect this
case as well.

Signed-off-by: Junio C Hamano

tests: create an interactive gdb session with the 'debug' helper

2017-03-18T17:18:20+00:00

The 'debug' test helper is supposed to facilitate debugging by running
a command of the test suite under gdb.  Unfortunately, its usefulness
is severely limited, because that gdb session is not interactive,
since the test's, and thus gdb's standard input is redirected from
/dev/null (for a good reason, see 781f76b15 (test-lib: redirect stdin
of tests, 2011-12-15)).

Redirect gdb's standard file descriptors from/to the test
environment's stdin, stdout and stderr in the 'debug' helper, thus
creating an interactive gdb session (even in non-verbose mode), which
is much, much more useful.

Signed-off-by: SZEDER Gábor 
Signed-off-by: Junio C Hamano

test-lib: on FreeBSD, look for unzip(1) in /usr/local/bin/

2017-01-27T18:55:26+00:00

Eric Wong reported that while FreeBSD has a /usr/bin/unzip, it uses
different semantics from those that are needed by Git's tests: When
passing the -a option to Info-Zip, it heeds the text attribute of the
.zip file's central directory, while FreeBSD's unzip ignores that
attribute.

The common work-around is to install Info-Zip on FreeBSD, into
/usr/local/bin/.

Signed-off-by: Johannes Schindelin 
Tested-by: Eric Wong 
Signed-off-by: Junio C Hamano

Merge branch 'nd/test-helpers'

2016-10-31T20:15:27+00:00

Update to the test framework made in 2.9 timeframe broke running
the tests under valgrind, which has been fixed.

* nd/test-helpers:
  valgrind: support test helpers

valgrind: support test helpers

2016-10-28T06:33:53+00:00

Tests run with --valgrind call git commands through a wrapper script
that invokes valgrind on them.  This script (valgrind.sh) is in turn
invoked through symlinks created for each command in t/valgrind/bin/.

Since e6e7530d (test helpers: move test-* to t/helper/ subdirectory)
these symlinks have been broken for test helpers -- they point to the
old locations in the root of the build directory.  Fix that by teaching
the code for creating the links about the new location of the binaries,
and do the same in the wrapper script to allow it to find its payload.

Signed-off-by: Rene Scharfe 
Signed-off-by: Junio C Hamano

Merge branch 'jk/tap-verbose-fix'

2016-10-26T20:14:54+00:00

The Travis CI configuration we ship ran the tests with --verbose
option but this risks non-TAP output that happens to be "ok" to be
misinterpreted as TAP signalling a test that passed.  This resulted
in unnecessary failure.  This has been corrected by introducing a
new mode to run our tests in the test harness to send the verbose
output separately to the log file.

* jk/tap-verbose-fix:
  test-lib: bail out when "-v" used under "prove"
  travis: use --verbose-log test option
  test-lib: add --verbose-log option
  test-lib: handle TEST_OUTPUT_DIRECTORY with spaces

test-lib: bail out when "-v" used under "prove"

2016-10-24T16:26:00+00:00

When there is a TAP harness consuming the output of our test
scripts, the "--verbose" breaks the output by mingling
test command output with TAP. Because the TAP::Harness
module used by "prove" is fairly lenient, this _usually_
works, but it violates the spec, and things get very
confusing if the commands happen to output a line that looks
like TAP (e.g., the word "ok" on its own line).

Let's detect this situation and complain. Just calling
error() isn't great, though; prove will tell us that the
script failed, but the message doesn't make it through to
the user. Instead, we can use the special TAP signal "Bail
out!". This not only shows the message to the user, but
instructs the harness to stop running the tests entirely.
This is exactly what we want here, as the problem is in the
command-line options, and every test script would produce
the same error.

The result looks like this (the first "Bailout called" line
is in red if prove uses color on your terminal):

 $ make GIT_TEST_OPTS='--verbose --tee'
 rm -f -r 'test-results'
 *** prove ***
 Bailout called.  Further testing stopped:  verbose mode forbidden under TAP harness; try --verbose-log
 FAILED--Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log
 Makefile:39: recipe for target 'prove' failed
 make: *** [prove] Error 255

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

test-lib: add --verbose-log option

2016-10-21T16:54:35+00:00

The "--verbose" option redirects output from arbitrary
test commands to stdout. This is useful for examining the
output manually, like:

  ./t5547-push-quarantine.sh -v | less

But it also means that the output is intermingled with the
TAP directives, which can confuse a TAP parser like "prove".
This has always been a potential problem, but became an
issue recently when one test happened to output the word
"ok" on a line by itself, which prove interprets as a test
success:

  $ prove t5547-push-quarantine.sh :: -v
  t5547-push-quarantine.sh .. 1/? To dest.git
   * [new branch]      HEAD -> master
  To dest.git
   ! [remote rejected] reject -> reject (pre-receive hook declined)
  error: failed to push some refs to 'dest.git'
  fatal: git cat-file d08c8eba97f4e683ece08654c7c8d2ba0c03b129: bad file
  t5547-push-quarantine.sh .. Failed -1/4 subtests

  Test Summary Report
  -------------------
  t5547-push-quarantine.sh (Wstat: 0 Tests: 5 Failed: 0)
    Parse errors: Tests out of sequence.  Found (2) but expected (3)
                  Tests out of sequence.  Found (3) but expected (4)
                  Tests out of sequence.  Found (4) but expected (5)
                  Bad plan.  You planned 4 tests but ran 5.
  Files=1, Tests=5,  0 wallclock secs ( 0.01 usr +  0.01 sys =  0.02 CPU)
  Result: FAIL

One answer is "if it hurts, don't do it", but that's not
quite the whole story. The Travis tests use "--verbose
--tee" so that they can get the benefit of prove's parallel
options, along with a verbose log in case there is a
failure. We just need the verbose output to go to the log,
but keep stdout clean.

Getting this right turns out to be surprisingly difficult.
Here's the progression of alternatives I considered:

 1. Add an option to write verbose output to stderr. This is
    hard to capture, though, because we want each test to
    have its own log (because they're all run in parallel
    and the jumbled output would be useless).

 2. Add an option to write verbose output to a file in
    test-results. This works, but the log is missing all of
    the non-verbose output, which gives context.

 3. Like (2), but teach say_color() to additionally output
    to the log. This mostly works, but misses any output
    that happens outside of the say() functions (which isn't
    a lot, but is a potential maintenance headache).

 4. Like (2), but make the log file the same as the "--tee"
    file. That almost works, but now we have two processes
    opening the same file. That gives us two separate
    descriptors, each with their own idea of the current
    position. They'll each start writing at offset 0, and
    overwrite each other's data.

 5. Like (4), but in each case open the file for appending.
    That atomically positions each write at the end of the
    file.

    It's possible we may still get sheared writes between
    the two processes, but this is already the case when
    writing to stdout. It's not a problem in practice
    because the test harness generally waits for snippets to
    finish before writing the TAP output.

    We can ignore buffering issues with tee, because POSIX
    mandates that it does not buffer. Likewise, POSIX
    specifies "tee -a", so it should be available
    everywhere.

This patch implements option (5), which seems to work well
in practice.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano