88
88
This causes the test to immediately exit upon the first
89
failed test. Cleanup commands requested with
90
test_when_finished are not executed if the test failed,
91
in order to keep the state for inspection by the tester
92
95
This causes additional long-running tests to be run (where
93
96
available), for more exhaustive testing.
96
Execute all Git binaries with valgrind and exit with status
97
126 on errors (just like regular tests, this will only stop
98
the test script when running under -i). Valgrind errors
99
go to stderr, so you might want to pass the -v option, too.
99
Execute all Git binaries under valgrind tool <tool> and exit
100
with status 126 on errors (just like regular tests, this will
101
only stop the test script when running under -i).
101
103
Since it makes no sense to run the tests with --valgrind and
102
104
not see any output, this option implies --verbose. For
103
105
convenience, it also implies --tee.
105
Note that valgrind is run with the option --leak-check=no,
107
<tool> defaults to 'memcheck', just like valgrind itself.
108
Other particularly useful choices include 'helgrind' and
109
'drd', but you may use any tool recognized by your valgrind
112
As a special case, <tool> can be 'memcheck-fast', which uses
113
memcheck but disables --track-origins. Use this if you are
114
running tests in bulk, to see if there are _any_ memory
117
Note that memcheck is run with the option --leak-check=no,
106
118
as the git process is short-lived and some errors are not
107
119
interesting. In order to run a single command under the same
108
120
conditions manually, you should set GIT_VALGRIND to point to
307
319
Use test_done instead if you need to stop the tests early (see
308
320
"Skipping tests" below).
322
- use '! git cmd' when you want to make sure the git command exits
323
with failure in a controlled way by calling "die()". Instead,
324
use 'test_must_fail git cmd'. This will signal a failure if git
325
dies in an unexpected way (e.g. segfault).
327
On the other hand, don't use test_must_fail for running regular
328
platform commands; just use '! cmd'.
330
- use perl without spelling it as "$PERL_PATH". This is to help our
331
friends on Windows where the platform Perl often adds CR before
332
the end of line, and they bundle Git with a version of Perl that
333
does not do so, whose path is specified with $PERL_PATH.
335
- use sh without spelling it as "$SHELL_PATH", when the script can
336
be misinterpreted by broken platform shell (e.g. Solaris).
338
- chdir around in tests. It is not sufficient to chdir to
339
somewhere and then chdir back to the original location later in
340
the test, as any intermediate step can fail and abort the test,
341
causing the next test to start in an unexpected directory. Do so
342
inside a subshell if necessary.
310
344
- Break the TAP output
312
346
The raw output from your test may be interpreted by a TAP harness. TAP
342
376
of the test_* functions (see the "Test harness library" section
345
test_expect_success PERL 'I need Perl' "
346
'$PERL_PATH' -e 'hlagh() if unf_unf()'
379
test_expect_success PERL 'I need Perl' '
380
"$PERL_PATH" -e "hlagh() if unf_unf()"
349
383
The advantage of skipping tests like this is that platforms that don't
350
384
have the PERL and other optional dependencies get an indication of how
606
645
Git was compiled with USE_LIBPCRE=YesPlease. Wrap any tests
607
646
that use git-grep --perl-regexp or git-grep -P in these.
648
- CASE_INSENSITIVE_FS
650
Test is run on a case insensitive file system.
654
Test is run on a filesystem which converts decomposed utf-8 (nfd)
655
to precomposed utf-8 (nfc).
609
657
Tips for Writing Tests
610
658
----------------------