Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 3月, 2015 1 次提交
    • J
      t/test-lib: introduce --chain-lint option · bb79af9d
      由 Jeff King 提交于 
      It's easy to miss an "&&"-chain in a test script, like:

  test_expect_success 'check something important' '
	cmd1 &&
	cmd2
	cmd3
  '

The test harness will notice if cmd3 fails, but a failure of
cmd1 or cmd2 will go unnoticed, as their exit status is lost
after cmd3 runs.

The toy example above is easy to spot because the "cmds" are
all the same length, but real code is much more complicated.
It's also difficult to detect these situations by statically
analyzing the shell code with regexps (like the
check-non-portable-shell script does); there's too much
context required to know whether a &&-chain is appropriate
on a given line or not.

This patch instead lets the shell check each test by
sticking a command with a specific and unusual return code
at the top of each test, like:

  (exit 117) &&
  cmd1 &&
  cmd2
  cmd3

In a well-formed test, the non-zero exit from the first
command prevents any of the rest from being run, and the
test's exit code is 117. In a bad test (like the one above),
the 117 is lost, and cmd3 is run.

When we encounter a failure of this check, we abort the test
script entirely. For one thing, we have no clue which subset
of the commands in the test snippet were actually run.
Running further tests would be pointless, because we're now
in an unknown state. And two, this is not a "test failure"
in the traditional sense. The test script is buggy, not the
code it is testing. We should be able to fix these problems
in the script once, and not have them come back later as a
regression in git's code.

After checking a test snippet for --chain-lint, we do still
run the test itself.  We could actually have a pure-lint
mode which just checks each test, but there are a few
reasons not to. One, because the tests are executing
arbitrary code, which could impact the later environment
(e.g., that could impact which set of tests we run at all).
And two, because a pure-lint mode would still be expensive
to run, because a significant amount of code runs outside of
the test_expect_* blocks.  Instead, this option is designed
to be used as part of a normal test suite run, where it adds
very little overhead.

Turning on this option detects quite a few problems in
existing tests, which will be fixed in subsequent patches.
However, there are a number of places it cannot reach:

 - it cannot find a failure to break out of loops on error,
   like:

     cmd1 &&
     for i in a b c; do
	     cmd2 $i
     done &&
     cmd3

   which will not notice failures of "cmd2 a" or "cmd b"

 - it cannot find a missing &&-chain inside a block or
   subfunction, like:

     foo () {
	     cmd1
	     cmd2
     }

     foo &&
     bar

   which will not notice a failure of cmd1.

 - it only checks tests that you run; every platform will
   have some tests skipped due to missing prequisites,
   so it's impossible to say from one run that the test
   suite is free of broken &&-chains. However, all tests get
   run by _somebody_, so eventually we will notice problems.

 - it does not operate on test_when_finished or prerequisite
   blocks. It could, but these tends to be much shorter and
   less of a problem, so I punted on them in this patch.

This patch was inspired by an earlier patch by Jonathan
Nieder:

  http://article.gmane.org/gmane.comp.version-control.git/235913

This implementation and all bugs are mine.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      bb79af9d
  3. 25 11月, 2014 1 次提交
  5. 14 10月, 2014 1 次提交
    • J
      test-lib.sh: support -x option for shell-tracing · a136f6d8
      由 Jeff King 提交于 
      Usually running a test under "-v" makes it clear which
command is failing. However, sometimes it can be useful to
also see a complete trace of the shell commands being run in
the test. You can do so without any support from the test
suite by running "sh -x tXXXX-foo.sh". However, this
produces quite a large bit of output, as we see a trace of
the entire test suite.

This patch instead introduces a "-x" option to the test
scripts (i.e., "./tXXXX-foo.sh -x"). When enabled, this
turns on "set -x" only for the tests themselves. This can
still be a bit verbose, but should keep things to a more
manageable level. You can even use "--verbose-only" to see
the trace only for a specific test.

The implementation is a little invasive. We turn on the "set
-x" inside the "eval" of the test code. This lets the eval
itself avoid being reported in the trace (which would be
long, and redundant with the verbose listing we already
showed). And then after the eval runs, we do some trickery
with stderr to avoid showing the "set +x" to the user.

We also show traces for test_cleanup functions (since they
can impact the test outcome, too). However, we do avoid
running the noop ":" cleanup (the default if the test does
not use test_cleanup at all), as it creates unnecessary
noise in the "set -x" output.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a136f6d8
  7. 11 6月, 2014 2 次提交
  9. 07 6月, 2014 2 次提交
  11. 30 10月, 2013 1 次提交
    • J
      t: provide a perl() function which uses $PERL_PATH · a0e0ec9f
      由 Jeff King 提交于 
      Once upon a time, we assumed that calling a bare "perl" in
the test scripts was OK, because we would find the perl from
the user's PATH, and we were only asking that perl to do
basic operations that work even on old versions of perl.

Later, we found that some systems really prefer to use
$PERL_PATH even for these basic cases, because the system
perl misbehaves in some way (e.g., by handling line endings
differently). We then switched "perl" invocations to
"$PERL_PATH" to respect the user's choice.

Having to use "$PERL_PATH" is ugly and cumbersome, though.
Instead, let's provide a perl() shell function that tests
can use, which will transparently do the right thing.

Unfortunately, test writers still have to use $PERL_PATH in
certain situations, so we still need to keep the advice in
the README.

Note that this may fix test failures in t5004, t5503, t6002,
t6003, t6300, t8001, and t8002, depending on your system's
perl setup. All of these can be detected by running:

  ln -s /bin/false bin-wrappers/perl
  make test

which fails before this patch, and passes after.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a0e0ec9f
  13. 29 10月, 2013 1 次提交
    • J
      t/README: tests can use perl even with NO_PERL · f8fc0ee3
      由 Jonathan Nieder 提交于 
      The git build system supports a NO_PERL switch to avoid installing
perl bindings or other features (like "git add --patch") that rely on
perl on runtime, but even with NO_PERL it has not been possible for a
long time to run tests without perl.  Helpers such as

	nul_to_q () {
		"$PERL_PATH" -pe 'y/\000/Q/'
	}

use perl as a better tr or sed and are regularly used in tests without
worrying to add a PERL prerequisite.

Perl is portable enough that it seems fine to keep relying on it for
this kind of thing in tests (and more readable than the alternative of
trying to find POSIXy equivalents).  Update the test documentation to
clarify this.
Reported-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f8fc0ee3
  15. 24 6月, 2013 2 次提交
    • T
      test-lib: valgrind for only tests matching a pattern · 5dfc368f
      由 Thomas Rast 提交于 
      With the new --valgrind-only=<pattern> option, one can enable
--valgrind at a per-test granularity, exactly analogous to
--verbose-only from the previous commit.

The options are wired such that --valgrind implies --verbose (as
before), but --valgrind-only=<pattern> implies
--verbose-only=<pattern> unless --verbose is also in effect.
Signed-off-by: NThomas Rast <trast@inf.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5dfc368f
    • T
      test-lib: verbose mode for only tests matching a pattern · ff09af3f
      由 Thomas Rast 提交于 
      With the new --verbose-only=<pattern> option, one can enable --verbose
at a per-test granularity.  The pattern is matched against the test
number, e.g.

  ./t0000-basic.sh --verbose-only='2[0-2]'

to see only the full output of test 20-22, while showing the rest in the
one-liner format.

As suggested by Jeff King, this takes care to wrap the entire
test_expect_* block, but nothing else, in the verbose toggling.  We
can use the test_start/end functions from the previous commit for the
purpose.

This is arguably not *too* useful on its own, but makes the next patch
easier to follow.
Helped-by: NJeff King <peff@peff.net>
Signed-off-by: NThomas Rast <trast@inf.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ff09af3f
  17. 08 6月, 2013 1 次提交
  19. 05 6月, 2013 1 次提交
    • J
      t/README: test_must_fail is for testing Git · f445500e
      由 Junio C Hamano 提交于 
      When a test wants to make sure there is no <string> in an output
file, we should just say "! grep string output".

"test_must_fail" is there only to test Git command and catch unusual
deaths we know about (e.g. segv) as an error, not as an expected
failure.  "test_must_fail grep string output" is unnecessary, as
we are not making sure the system binaries do not dump core or
anything like that.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f445500e
  21. 12 4月, 2013 1 次提交
  23. 10 4月, 2013 1 次提交
  25. 01 4月, 2013 3 次提交
  27. 28 7月, 2012 2 次提交
  29. 25 6月, 2012 1 次提交
    • J
      t/README: add a bit more Don'ts · ad78585e
      由 Junio C Hamano 提交于 
      Add a few more advices that we often have to give to new test
writers.

Also update an example where a double quote pair is used to enclose
a test body to use a single quote pair, which is more readable and
more importantly gives saner semantics for variable substitution.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ad78585e
  31. 13 2月, 2012 1 次提交
    • Æ
      Remove Git's support for smoke testing · d24fbca7
      由 Ævar Arnfjörð Bjarmason 提交于 
      I'm no longer running the Git smoke testing service at
smoke.git.nix.is due to Smolder being a fragile piece of software not
having time to follow through on making it easy for third parties to
run and submit their own smoke tests.

So remove the support in Git for sending smoke tests to
smoke.git.nix.is, it's still easy to modify the test suite to submit
smokes somewhere else.

This reverts the following commits:

    Revert "t/README: Add SMOKE_{COMMENT,TAGS}= to smoke_report target" -- e38efac8
    Revert "t/README: Document the Smoke testing" -- d15e9ebc
    Revert "t/Makefile: Create test-results dir for smoke target" -- 617344d7
    Revert "tests: Infrastructure for Git smoke testing" -- b6b84d1bSigned-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d24fbca7
  33. 18 1月, 2012 1 次提交
    • J
      test-lib: add the test_pause convenience function · c4d2539a
      由 Jens Lehmann 提交于 
      Since 781f76b1 (test-lib: redirect stdin of tests) you can't simply put a
"bash &&" into a test for debugging purposes anymore. Instead you'll have
to use "bash <&6 >&3 2>&4".

As that invocation is not that easy to remember add the test_pause
convenience function. It invokes "$SHELL_PATH" to provide a sane shell
for the user.

This function also checks if the -v flag is given and will error out if
that is not the case instead of letting the test hang until ^D is pressed.
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c4d2539a
  35. 10 5月, 2011 1 次提交
  37. 27 4月, 2011 1 次提交
  39. 31 3月, 2011 1 次提交
  41. 21 3月, 2011 1 次提交
  43. 16 3月, 2011 1 次提交
  45. 10 3月, 2011 1 次提交
  47. 12 1月, 2011 1 次提交
  49. 10 11月, 2010 1 次提交
    • J
      test-lib: introduce test_line_count to measure files · fb3340a6
      由 Jonathan Nieder 提交于 
      Some tests check their output with code like the following:

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

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

Introduce a test_line_count function to help. If used like

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

it will produce output like

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

on failure.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      fb3340a6
  51. 27 10月, 2010 1 次提交
  53. 07 10月, 2010 2 次提交
  55. 19 8月, 2010 6 次提交