summaryrefslogtreecommitdiff
path: root/t/test-lib.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-01-10Merge branch 'jk/test-framework-updates'Libravatar Junio C Hamano1-2/+0
The basic test used to leave unnecessary trash directories in the t/ directory. * jk/test-framework-updates: t0000: drop "known breakage" test t0000: simplify HARNESS_ACTIVE hack t0000: set TEST_OUTPUT_DIRECTORY for sub-tests
2014-01-02t0000: simplify HARNESS_ACTIVE hackLibravatar Jeff King1-2/+0
Commit 517cd55 set HARNESS_ACTIVE unconditionally in sub-tests, because that value affects the output of "--verbose". t0000 needs stable output from its sub-tests, and we may or may not be running under a TAP harness. That commit made the decision to always set the variable, since it has another useful side effect, which is suppressing writes to t/test-results by the sub-tests (which would just pollute the real results). Since the last commit, though, the sub-tests have their own test-results directories, so this is no longer an issue. We can now update a few comments that are no longer accurate nor necessary. We can also revisit the choice of HARNESS_ACTIVE. Since we must choose one value for stability, it's probably saner to have it off. This means that future patches could test things like the test-results writing, or the "--quiet" option, which is currently ignored when run under a harness. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12Merge branch 'jn/scripts-updates'Libravatar Junio C Hamano1-5/+7
* jn/scripts-updates: remove #!interpreter line from shell libraries test: replace shebangs with descriptions in shell libraries test: make FILEMODE a lazy prereq contrib: remove git-p4import mark contributed hooks executable mark perl test scripts executable mark Windows build scripts executable
2013-11-26remove #!interpreter line from shell librariesLibravatar Jonathan Nieder1-4/+2
In a shell snippet meant to be sourced by other shell scripts, an opening #! line does more harm than good. The harm: - When the shell library is sourced, the interpreter and options from the #! line are not used. Specifying a particular shell can confuse the reader into thinking it is safe for the shell library to rely on idiosyncrasies of that shell. - Using #! instead of a plain comment drops a helpful visual clue that this is a shell library and not a self-contained script. - Tools such as lintian can use a #! line to tell when an installation script has failed by forgetting to set a script executable. This check does not work if shell libraries also start with a #! line. The good: - Text editors notice the #! line and use it for syntax highlighting if you try to edit the installed scripts (without ".sh" suffix) in place. The use of the #! for file type detection is not needed because Git's shell libraries are meant to be edited in source form (with ".sh" suffix). Replace the opening #! lines with comments. This involves tweaking the test harness's valgrind support to find shell libraries by looking for "# " in the first line instead of "#!" (see v1.7.6-rc3~7, 2011-06-17). Suggested by Russ Allbery through lintian. Thanks to Jeff King and Clemens Buchacher for further analysis. Tested by searching for non-executable scripts with #! line: find . -name .git -prune -o -type f -not -executable | while read file do read line <"$file" case $line in '#!'*) echo "$file" ;; esac done The only remaining scripts found are templates for shell scripts (unimplemented.sh, wrap-for-bin.sh) and sample input used in tests (t/t4034/perl/{pre,post}). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-26test: replace shebangs with descriptions in shell librariesLibravatar Jonathan Nieder1-1/+1
A #! line in these files is misleading, since these scriptlets are meant to be sourced with '.' (using whatever shell sources them) instead of run directly using the interpreter named on the #! line. Removing the #! line shouldn't hurt syntax highlighting since these files have filenames ending with '.sh'. For documentation, add a brief description of how the files are meant to be used in place of the shebang line. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-26test: make FILEMODE a lazy prereqLibravatar Jonathan Nieder1-0/+4
This way, test authors don't need to remember to source lib-prereq-FILEMODE.sh before using the FILEMODE prereq to guard tests that rely on the executable bit being honored when checking out files. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18test-lib.sh: convert $TEST_DIRECTORY to an absolute pathLibravatar Felipe Contreras1-0/+4
If $TEST_DIRECTORY is specified in the environment, convert the value to an absolute path to ensure that it remains valid even when 'cd' is used. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-01Merge branch 'js/tests-windows-port-fix'Libravatar Junio C Hamano1-0/+1
* js/tests-windows-port-fix: tests: undo special treatment of CRLF for Windows Windows: a test_cmp that is agnostic to random LF <> CRLF conversions t5300-pack-object: do not compare binary data using test_cmp
2013-10-30Merge branch 'tr/valgrind-test-fix'Libravatar Junio C Hamano1-99/+34
* tr/valgrind-test-fix: Revert "test-lib: allow prefixing a custom string before "ok N" etc." Revert "test-lib: support running tests under valgrind in parallel"
2013-10-28Sync with v1.8.4.2Libravatar Junio C Hamano1-1/+1
2013-10-28test-lib: fix typo in commentLibravatar Torstein Hegge1-1/+1
Point test writers to the test_expect_* functions properly. Signed-off-by: Torstein Hegge <hegge@resisty.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-28Windows: a test_cmp that is agnostic to random LF <> CRLF conversionsLibravatar Johannes Sixt1-0/+1
In a number of tests, output that was produced by a shell script is compared to expected output using test_cmp. Unfortunately, the MSYS bash-- when invoked via git, such as in hooks--converts LF to CRLF on output (as produced by echo and printf), which leads to many false positives. Implements a diff tool that undoes the converted CRLF. To avoid that sub-processes are spawned (which is very slow on Windows), the tool is implemented as a shell function. Diff is invoked as usual only when a difference is detected by the shell code. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-22Revert "test-lib: allow prefixing a custom string before "ok N" etc."Libravatar Thomas Rast1-15/+12
Now that ad0e623 (test-lib: support running tests under valgrind in parallel, 2013-06-23) has been reverted, this support code has no users any more. Revert it, too. This reverts commit e939e15d241e942662b9f88f6127ab470ab0a0b9. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-22Revert "test-lib: support running tests under valgrind in parallel"Libravatar Thomas Rast1-84/+22
This reverts commit ad0e6233320b004f0d686f6887c803e508607bd2. --valgrind-parallel was broken from the start: during review I made the whole valgrind setup code conditional on not being a --valgrind-parallel worker child. But even the children crucially need $GIT_VALGRIND to be set; it should therefore have been set outside the conditional. The fix would be a two-liner, but since the introduction of the feature, almost four months have passed without anyone noticing that it is broken. So this feature is not worth the about hundred lines of test-lib.sh complexity. Revert it. Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09git_remote_helpers: remove little used Python libraryLibravatar John Keeping1-9/+0
When it was originally added, the git_remote_helpers library was used as part of the tests of the remote-helper interface, but since commit fc407f9 (Add new simplified git-remote-testgit, 2012-11-28) a simple shell script is used for this. A search on Ohloh [1] indicates that this library isn't used by any external projects and even the Python remote helpers in contrib/ don't use this library, so it is only used by its own test suite. Since this is the only Python library in Git, removing it will make packaging easier as the Python scripts only need to be installed for one version of Python, whereas the library should be installed for all available versions. [1] http://code.ohloh.net/search?s=%22git_remote_helpers%22 Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24Merge branch 'ml/avoid-using-grep-on-crlf-files'Libravatar Junio C Hamano1-0/+2
On systems that understand a CRLF as a line ending, tests in this script that worked on files with CRLF line endings using "grep" to extract matching lines may lose the CR at the end of lines that match, causing the actual output not to match the expected output. * ml/avoid-using-grep-on-crlf-files: test-lib.sh - define and use GREP_STRIPS_CR
2013-07-18test-lib.sh - define and use GREP_STRIPS_CRLibravatar Mark Levedahl1-0/+2
Define a common macro for grep needing -U to allow tests to not need to inquire of specific platforms needing this option. Change t3032 and t5560 to use this rather than testing explicitly for mingw. This fixes these two tests on Cygwin. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18Merge branch 'bp/mediawiki-preview'Libravatar Junio C Hamano1-0/+1
Add a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. I personally do not think this belongs to Git. If you are working on a set of AsciiDoc source files, you sure do want to locally format to preview what you will be pushing out, and if you are working on a set of C or Java source files, you do want to test it before pushing it out, too. That kind of thing belongs to your build script, not to your SCM. But I'll let it pass, as this is only a contrib/ thing. * bp/mediawiki-preview: git-remote-mediawiki: add preview subcommand into git mw git-remote-mediawiki: add git-mw command git-remote-mediawiki: factoring code between git-remote-mediawiki and Git::Mediawiki git-remote-mediawiki: update tests to run with the new bin-wrapper git-remote-mediawiki: add a git bin-wrapper for developement wrap-for-bin: make bin-wrappers chainable git-remote-mediawiki: introduction of Git::Mediawiki.pm
2013-07-12Merge branch 'ml/cygwin-does-not-have-fifo'Libravatar Junio C Hamano1-1/+8
* ml/cygwin-does-not-have-fifo: test-lib.sh - cygwin does not have usable FIFOs
2013-07-08wrap-for-bin: make bin-wrappers chainableLibravatar Benoit Person1-0/+1
For now, bin-wrappers overwrites GITPERLLIB. If we want to chain to those scripts and define GITPERLLIB before, our changes will be discarded. This patch makes the bin-wrappers prepend their modifications to GITPERLLIB rather than redefining it. It also unset GITPERLLIB in the test-suite to prevent broken $GITPERLLIB in the user's configuration from interfering with the testsuite. The codes using GIT_TEMPLATE_DIR and GIT_TEXTDOMAINDIR handle only one path in each of this variable so this new behavior would be useless on those variables. Signed-off-by: Benoit Person <benoit.person@ensimag.fr> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05Merge branch 'tr/test-v-and-v-subtest-only'Libravatar Junio C Hamano1-49/+197
Allows N instances of tests run in parallel, each running 1/N parts of the test suite under Valgrind, to speed things up. * tr/test-v-and-v-subtest-only: perf-lib: fix start/stop of perf tests test-lib: support running tests under valgrind in parallel test-lib: allow prefixing a custom string before "ok N" etc. test-lib: valgrind for only tests matching a pattern test-lib: verbose mode for only tests matching a pattern test-lib: self-test that --verbose works test-lib: rearrange start/end of test_expect_* and test_skip test-lib: refactor $GIT_SKIP_TESTS matching test-lib: enable MALLOC_* for the actual tests
2013-07-05test-lib.sh - cygwin does not have usable FIFOsLibravatar Mark Levedahl1-1/+8
Do not use FIFOs on cygwin, they do not work. Cygwin includes coreutils, so has mkfifo, and that command does something. However, the resultant named pipe is known (on the Cygwin mailing list at least) to not work correctly. This disables PIPE for Cygwin, allowing t0008.sh to complete (all other tests in that file work correctly). Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23test-lib: support running tests under valgrind in parallelLibravatar Thomas Rast1-22/+84
With the new --valgrind-parallel=<n> option, we support running the tests in a single test script under valgrind in parallel using 'n' processes. This really follows the dumbest approach possible, as follows: * We spawn the test script 'n' times, using a throw-away TEST_OUTPUT_DIRECTORY. Each of the instances is given options that ensures that it only runs every n-th test under valgrind, but together they cover the entire range. * We add up the numbers from the individual tests, and provide the usual output. This is really a gross hack at this point, and should be improved. In particular we should keep the actual outputs somewhere more easily discoverable, and summarize them to the user. Nevertheless, this is already workable and gives a speedup of more than 2 on a dual-core (hyperthreaded) machine, using n=4. This is expected since the overhead of valgrind is so big (on the order of 20x under good conditions, and a large startup overhead at every git invocation) that redundantly running the non-valgrind tests in between is not that expensive. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23test-lib: allow prefixing a custom string before "ok N" etc.Libravatar Thomas Rast1-12/+15
This is not really meant for external use, and thus not documented. It allows the next commit to neatly distinguish between sub-tests and the main run. The format is intentionally not valid TAP. The use in the next commit would not result in anything valid either way, and it seems better to make it obvious. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23test-lib: valgrind for only tests matching a patternLibravatar Thomas Rast1-1/+35
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: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23test-lib: verbose mode for only tests matching a patternLibravatar Thomas Rast1-0/+31
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: Jeff King <peff@peff.net> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23test-lib: self-test that --verbose worksLibravatar Thomas Rast1-0/+2
t0000 contains some light self-tests of test-lib.sh, but --verbose was not covered. Add a test. The only catch is that the presence of a test harness influences the output (specifically, the presence of some empty lines). So we need to unset TEST_HARNESS or set it to a known value. Leaving it unset leads to spurious test failures in the final summary, which come from the subtest. So we always set it. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-18test-lib: rearrange start/end of test_expect_* and test_skipLibravatar Thomas Rast1-1/+8
This moves * the early setup part from test_skip to a new function test_start_ * the final common parts of test_expect_* to a new function test_finish_ to make the next commit more obvious. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-18test-lib: refactor $GIT_SKIP_TESTS matchingLibravatar Thomas Rast1-17/+24
It's already used twice, and we will have more of the same kind of matching in a minute. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17test-lib: enable MALLOC_* for the actual testsLibravatar Thomas Rast1-0/+2
1b3185f (MALLOC_CHECK: various clean-ups, 2012-09-14) moved around the MALLOC_CHECK_ and MALLOC_PERTURB_ assignments, intending to limit their effect to only the test runs. However, they were actually enabled only during test cleanup. Call setup/teardown_malloc_check also around the evaluation of the actual test snippet. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29Merge branch 'jk/test-output'Libravatar Junio C Hamano1-2/+2
When TEST_OUTPUT_DIRECTORY setting is used, it was handled somewhat inconsistently between the test framework and t/Makefile, and logic to summarize the results looked at a wrong place. * jk/test-output: t/Makefile: don't define TEST_RESULTS_DIRECTORY recursively test output: respect $TEST_OUTPUT_DIRECTORY t/Makefile: fix result handling with TEST_OUTPUT_DIRECTORY
2013-04-29test output: respect $TEST_OUTPUT_DIRECTORYLibravatar John Keeping1-2/+2
Most test results go in $TEST_OUTPUT_DIRECTORY, but the output files for tests run with --tee or --valgrind just use bare "test-results". Changes these so that they do respect $TEST_OUTPUT_DIRECTORY. As a result of this, the valgrind/analyze.sh script may no longer inspect the correct files so it is also updated to respect $TEST_OUTPUT_DIRECTORY by adding it to GIT-BUILD-OPTIONS. This may be a regression for people who have TEST_OUTPUT_DIRECTORY in their config.mak but want to override it in the environment, but this change merely brings it into line with GIT_TEST_OPTS which already cannot be overridden if it is specified in config.mak. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18Merge branch 'jk/test-trash'Libravatar Junio C Hamano1-9/+9
Fix longstanding issues with the test harness when used with --root=<there> option. * jk/test-trash: t/test-lib.sh: drop "$test" variable t/test-lib.sh: fix TRASH_DIRECTORY handling
2013-04-14t/test-lib.sh: drop "$test" variableLibravatar Jeff King1-5/+5
The $test variable is used as an interim buffer for constructing $TRASH_DIRECTORY, and is almost compatible with it (the exception being that $test has not been converted to an absolute path). Let's get rid of it entirely so that later code does not accidentally use it, thinking the two are interchangeable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-14t/test-lib.sh: fix TRASH_DIRECTORY handlingLibravatar John Keeping1-4/+4
After the location of $TRASH_DIRECTORY is adjusted by $TEST_OUTPUT_DIRECTORY, we go on to use the $test variable to make the trash directory and cd into it. This means that when $TEST_OUTPUT_DIRECTORY is not "." and an absolute --root has not been specified, we do not remove the trash directory once the tests are complete (remove_trash is set to $TRASH_DIRECTORY). Fix this by always referring to the trash directory as $TRASH_DIRECTORY. Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Jeff King <peff@peff.net> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11Merge branch 'maint'Libravatar Junio C Hamano1-0/+5
* maint: Typo fix: replacing it's -> its t: make PIPE a standard test prerequisite archive: clarify explanation of --worktree-attributes t/README: --immediate skips cleanup commands for failed tests
2013-04-11t: make PIPE a standard test prerequisiteLibravatar Adam Spiers1-0/+5
The 'PIPE' test prerequisite was already defined identically by t9010 and t9300, therefore it makes sense to make it a predefined prerequisite. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Merge branch 'jk/empty-archive' into maintLibravatar Junio C Hamano1-0/+6
"git archive" reports a failure when asked to create an archive out of an empty tree. It would be more intuitive to give an empty archive back in such a case. * jk/empty-archive: archive: handle commits with an empty tree test-lib: factor out $GIT_UNZIP setup
2013-04-01tests: parameterize --valgrind optionLibravatar Thomas Rast1-1/+9
Running tests under helgrind and DRD recently proved useful in tracking down thread interaction issues. This can unfortunately not be done through GIT_VALGRIND_OPTIONS because any tool other than memcheck would complain about unknown options. Let --valgrind take an optional parameter that describes the valgrind tool to invoke. The default mode is to run memcheck as before. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25Merge branch 'jk/empty-archive'Libravatar Junio C Hamano1-0/+6
"git archive" reports a failure when asked to create an archive out of an empty tree. It would be more intuitive to give an empty archive back in such a case. * jk/empty-archive: archive: handle commits with an empty tree test-lib: factor out $GIT_UNZIP setup
2013-03-10test-lib: factor out $GIT_UNZIP setupLibravatar Jeff King1-0/+6
We set up the $GIT_UNZIP variable and lazy prereq in multiple places (and the next patch is about to add another one). Let's factor it out to avoid repeating ourselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07Merge branch 'nd/fix-perf-parameters-in-tests' into maintLibravatar Junio C Hamano1-1/+1
* nd/fix-perf-parameters-in-tests: test-lib.sh: unfilter GIT_PERF_*
2013-01-26git p4 test: translate windows paths for cygwinLibravatar Pete Wyckoff1-0/+3
Native windows binaries do not understand posix-like path mapping offered by cygwin. Convert paths to native using "cygpath --windows" before presenting them to p4d. This is done using the AltRoots mechanism of p4. Both the posix and windows forms are put in the client specification, allowing p4 to find its location by native path even though the environment reports a different PWD. Shell operations in tests will use the normal form of $cli, which will look like a posix path in cygwin, while p4 will use AltRoots to match against the windows form of the working directory. This mechanism also handles the symlink issue that was fixed in 23bd0c9 (git p4 test: use real_path to resolve p4 client symlinks, 2012-06-27). Now that every p4 client view has an AltRoots with the real_path in it, explicitly calculating the real_path elsewhere is not necessary. Thanks-to: Sebastian Schuberth <sschuberth@gmail.com> Thanks-to: Johannes Sixt <j6t@kdbg.org> fixup! git p4 test: translate windows paths for cygwin Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-20Merge branch 'rs/zip-tests' into maintLibravatar Junio C Hamano1-0/+2
* rs/zip-tests: t5003: check if unzip supports symlinks t5000, t5003: move ZIP tests into their own script t0024, t5000: use test_lazy_prereq for UNZIP t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
2013-01-18Merge branch 'nd/fix-perf-parameters-in-tests'Libravatar Junio C Hamano1-1/+1
Allow GIT_PERF_* environment variables to be passed through the test framework. * nd/fix-perf-parameters-in-tests: test-lib.sh: unfilter GIT_PERF_*
2013-01-15test-lib.sh: unfilter GIT_PERF_*Libravatar Nguyễn Thái Ngọc Duy1-1/+1
These variables are user parameters to control how to run the perf tests. Allow users to do so. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-11Merge branch 'rs/zip-tests'Libravatar Junio C Hamano1-0/+2
Update zip tests to skip some that cannot be handled on platform unzip. * rs/zip-tests: t5003: check if unzip supports symlinks t5000, t5003: move ZIP tests into their own script t0024, t5000: use test_lazy_prereq for UNZIP t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
2013-01-06t0024, t5000: clear variable UNZIP, use GIT_UNZIP insteadLibravatar René Scharfe1-0/+2
InfoZIP's unzip takes default parameters from the environment variable UNZIP. Unset it in the test library and use GIT_UNZIP for specifying alternate versions of the unzip command instead. t0024 wasn't even using variable for the actual extraction. t5000 was, but when setting it to InfoZIP's unzip it would try to extract from itself (because it treats the contents of $UNZIP as parameters), which failed of course. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-03Merge branch 'as/test-tweaks'Libravatar Junio C Hamano1-11/+18
Output from the tests is coloured using "green is okay, yellow is questionable, red is bad and blue is informative" scheme. * as/test-tweaks: tests: paint unexpectedly fixed known breakages in bold red tests: test the test framework more thoroughly tests: refactor mechanics of testing in a sub test-lib tests: change info messages from yellow/brown to cyan tests: paint skipped tests in blue tests: paint known breakages in yellow tests: test number comes first in 'not ok $count - $message'
2012-12-20tests: paint unexpectedly fixed known breakages in bold redLibravatar Adam Spiers1-4/+9
Change color of unexpectedly fixed known breakages to bold red. An unexpectedly passing test indicates that the test code is somehow broken or out of sync with the code it is testing. Either way this is an error which is potentially as bad as a failing test, and as such is no longer portrayed as a pass in the output. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>