summaryrefslogtreecommitdiff
path: root/t/README
AgeCommit message (Collapse)AuthorFilesLines
2009-02-03Tests: let --valgrind imply --verbose and --teeLibravatar Johannes Schindelin1-0/+4
It does not make much sense to run the (expensive) valgrind tests and not look at the output. To prevent output from scrolling out of reach, the parameter --tee is implied, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-03test-lib.sh: optionally output to test-results/$TEST.out, tooLibravatar Johannes Schindelin1-0/+6
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-03Add valgrind support in test scriptsLibravatar Johannes Schindelin1-1/+7
This patch adds the ability to use valgrind's memcheck tool to diagnose memory problems in Git while running the test scripts. It requires valgrind 3.4.0 or newer. It works by creating symlinks to a valgrind script, which have the same name as our Git binaries, and then putting that directory in front of the test script's PATH as well as set GIT_EXEC_PATH to that directory. Git scripts are symlinked from that directory directly. That way, Git binaries called by Git scripts are valgrinded, too. Valgrind can be used by specifying "GIT_TEST_OPTS=--valgrind" in the make invocation. Any invocation of git that finds any errors under valgrind will exit with failure code 126. Any valgrind output will go to the usual stderr channel for tests (i.e., /dev/null, unless -v has been specified). If you need to pass options to valgrind -- you might want to run another tool than memcheck, for example -- you can set the environment variable GIT_VALGRIND_OPTIONS. A few default suppressions are included, since libz seems to trigger quite a few false positives. We'll assume that libz works and that we can ignore any errors which are reported there. Note: it is safe to run the valgrind tests in parallel, as the links in t/valgrind/bin/ are created using proper locking. Initial patch and all the hard work by Jeff King. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-28test-lib.sh: introduce test_commit() and test_merge() helpersLibravatar Johannes Schindelin1-0/+18
Often we just need to add a commit with a given (short) name, that will be tagged with the same name. Now, relatively complicated graphs can be constructed easily and in a clear fashion: test_commit A && test_commit B && git checkout A && test_commit C && test_merge D B will construct this graph: A - B \ \ C - D For simplicity, files whose name is the lower case version of the commit message (to avoid a warning about ambiguous names) will be committed, with the corresponding commit messages as contents. If you need to provide a different file/different contents, you can use the more explicit form test_commit $MESSAGE $FILENAME $CONTENTS Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-21t/README: Add 'Skipping Tests' section below 'Running Tests'Libravatar Jakub Narebski1-0/+28
Add description of GIT_SKIP_TESTS variable, taken almost verbatim (adjusting for conventions in t/README) from the commit message in 04ece59 (GIT_SKIP_TESTS: allow users to omit tests that are known to break) Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-19test-lib.sh: add --long-tests optionLibravatar Lea Wiemann1-0/+4
Add a --long-tests option to test-lib.sh, which enables tests to selectively run more exhaustive (longer running, potentially brute-force) tests. Such exhaustive tests would only be useful if one works on the specific module that is being tested -- for a general "cd t/; make" to check whether everything is OK, such exhaustive tests shouldn't be run by default since the longer it takes to run the tests, the less often they are actually run. Signed-off-by: Lea Wiemann <LeWiemann@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-18t/Makefile: "trash" directory was renamed recentlyLibravatar Brandon Casey1-1/+1
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01Sane use of test_expect_failureLibravatar Junio C Hamano1-8/+6
Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-01-12use 'init' instead of 'init-db' for shipped docs and toolsLibravatar Nicolas Pitre1-1/+1
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29Add info about new test families (8 and 9) to t/READMELibravatar Jakub Narebski1-0/+2
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28t/README: start testing porcelainishLibravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07Big tool rename.Libravatar Junio C Hamano1-5/+5
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-07[PATCH] Prevent t6000 series from dropping useless sed.script in t/Libravatar Junio C Hamano1-0/+8
The Makefile in the test suite directory considers any file matching t[0-9][0-9][0-9][0-9]-*.sh as the top-level test script to be executed. Unfortunately this was not documented, and the common test library, t6000-lib.sh was named to match that pattern. This caused t6000-lib.sh to be called from Makefile as the top-level program, causing it to leave t/sed.script file behind. Rename it to t6000lib.sh to prevent this, and document the naming convention a bit more clearly. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-16[PATCH 4/4] Trivial test harness fixes.Libravatar Junio C Hamano1-2/+3
The documentation of the test harness still refer to old numbering and also contains an obvious typo. Also "make test" should be run after making sure we have built all binaries, since test is designed to test the newly built ones. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Petr Baudis <pasky@ucw.cz>
2005-05-15Rename some test scripts and describe the naming conventionLibravatar Petr Baudis1-1/+26
First digit: "family", e.g. the absolute basics and global stuff (0), the basic db-side commands (read-tree, write-tree, commit-tree), the basic working-tree-side commands (checkout-cache, update-cache), the other basic commands (ls-files), the diff commands, the pull commands, exporting commands, revision tree commands... Second digit: the particular command we are testing Third digit: (optionally) the particular switch or group of switches we are testing Freeform part: commandname-details Described in the README. mv t1000-checkout-cache.sh t2000-checkout-cache-clash.sh mv t1001-checkout-cache.sh t2001-checkout-cache-clash.sh mv t0200-update-cache.sh t2010-update-cache-badpath.sh mv t0400-ls-files.sh t3000-ls-files-others.sh mv t0500-ls-files.sh t3010-ls-files-killed.sh
2005-05-14[PATCH 2/2] Test framework documentation.Libravatar Junio C Hamano1-0/+174
This adds instruction for running tests, and writing new tests. Signed-off-by: Junio C Hamano <junkio@cox.net> Updated to the new tidied up output style. Signed-off-by: Petr Baudis <pasky@ucw.cz>