diff options
Diffstat (limited to 't/README')
| -rw-r--r-- | t/README | 130 |
1 files changed, 43 insertions, 87 deletions
@@ -79,6 +79,10 @@ appropriately before running "make". --debug:: This may help the person who is developing a new test. It causes the command defined with test_debug to run. + The "trash" directory (used to store all temporary data + during testing) is not deleted even if there are no + failed tests so that you can inspect its contents after + the test finished. --immediate:: This causes the test to immediately exit upon the first @@ -98,6 +102,13 @@ appropriately before running "make". not see any output, this option implies --verbose. For convenience, it also implies --tee. + Note that valgrind is run with the option --leak-check=no, + as the git process is short-lived and some errors are not + interesting. In order to run a single command under the same + conditions manually, you should set GIT_VALGRIND to point to + the 't/valgrind/' directory and use the commands under + 't/valgrind/bin/'. + --tee:: In addition to printing the test output to the terminal, write it to files named 't/test-results/$TEST_NAME.out'. @@ -190,7 +201,7 @@ we are testing. If you create files under t/ directory (i.e. here) that is not the top-level test script, never name the file to match the above pattern. The Makefile here considers all such files as the -top-level test script and tries to run all of them. A care is +top-level test script and tries to run all of them. Care is especially needed if you are creating a common test library file, similar to test-lib.sh, because such a library file may not be suitable for standalone execution. @@ -274,9 +285,8 @@ Do: - Check the test coverage for your tests. See the "Test coverage" below. - Don't blindly follow test coverage metrics, they're a good way to - spot if you've missed something. If a new function you added - doesn't have any coverage you're probably doing something wrong, + Don't blindly follow test coverage metrics; if a new function you added + doesn't have any coverage, then you're probably doing something wrong, but having 100% coverage doesn't necessarily mean that you tested everything. @@ -328,7 +338,7 @@ Keep in mind: Skipping tests -------------- -If you need to skip tests you should do so be using the three-arg form +If you need to skip tests you should do so by using the three-arg form of the test_* functions (see the "Test harness library" section below), e.g.: @@ -369,7 +379,7 @@ library for your script to use. - test_expect_success [<prereq>] <message> <script> - Usually takes two strings as parameter, and evaluates the + Usually takes two strings as parameters, and evaluates the <script>. If it yields success, test is considered successful. <message> should state what it is testing. @@ -380,7 +390,7 @@ library for your script to use. 'tree=$(git-write-tree)' If you supply three parameters the first will be taken to be a - prerequisite, see the test_set_prereq and test_have_prereq + prerequisite; see the test_set_prereq and test_have_prereq documentation below: test_expect_success TTY 'git --paginate rev-list uses a pager' \ @@ -420,7 +430,7 @@ library for your script to use. - test_tick Make commit and tag names consistent by setting the author and - committer times to defined stated. Subsequent calls will + committer times to defined state. Subsequent calls will advance the times by a fixed amount. - test_commit <message> [<filename> [<contents>]] @@ -436,7 +446,7 @@ library for your script to use. Merges the given rev using the given message. Like test_commit, creates a tag and calls test_tick before committing. - - test_set_prereq SOME_PREREQ + - test_set_prereq <prereq> Set a test prerequisite to be used later with test_have_prereq. The test-lib will set some prerequisites for you, see the @@ -446,7 +456,7 @@ library for your script to use. test_have_prereq directly, or the three argument invocation of test_expect_success and test_expect_failure. - - test_have_prereq SOME PREREQ + - test_have_prereq <prereq> Check if we have a prerequisite previously set with test_set_prereq. The most common use of this directly is to skip @@ -516,12 +526,13 @@ library for your script to use. Check whether a file has the length it is expected to. - - test_path_is_file <file> [<diagnosis>] - test_path_is_dir <dir> [<diagnosis>] + - test_path_is_file <path> [<diagnosis>] + test_path_is_dir <path> [<diagnosis>] test_path_is_missing <path> [<diagnosis>] - Check whether a file/directory exists or doesn't. <diagnosis> will - be displayed if the test fails. + Check if the named path is a file, if the named path is a + directory, or if the named path does not exist, respectively, + and fail otherwise, showing the <diagnosis> text. - test_when_finished <script> @@ -537,6 +548,19 @@ library for your script to use. ... ' + - test_pause + + This command is useful for writing and debugging tests and must be + removed before submitting. It halts the execution of the test and + spawns a shell in the trash directory. Exit the shell to continue + the test. Example: + + test_expect_success 'test' ' + git do-something >actual && + test_pause && + test_cmp expected actual + ' + Prerequisites ------------- @@ -577,6 +601,11 @@ use these, and "test_set_prereq" for how to define your own. Test is not run by root user, and an attempt to write to an unwritable file is expected to fail correctly. + - LIBPCRE + + Git was compiled with USE_LIBPCRE=YesPlease. Wrap any tests + that use git-grep --perl-regexp or git-grep -P in these. + Tips for Writing Tests ---------------------- @@ -642,76 +671,3 @@ Then, at the top-level: That'll generate a detailed cover report in the "cover_db_html" directory, which you can then copy to a webserver, or inspect locally in a browser. - -Smoke testing -------------- - -The Git test suite has support for smoke testing. Smoke testing is -when you submit the results of a test run to a central server for -analysis and aggregation. - -Running a smoke tester is an easy and valuable way of contributing to -Git development, particularly if you have access to an uncommon OS on -obscure hardware. - -After building Git you can generate a smoke report like this in the -"t" directory: - - make clean smoke - -You can also pass arguments via the environment. This should make it -faster: - - GIT_TEST_OPTS='--root=/dev/shm' TEST_JOBS=10 make clean smoke - -The "smoke" target will run the Git test suite with Perl's -"TAP::Harness" module, and package up the results in a .tar.gz archive -with "TAP::Harness::Archive". The former is included with Perl v5.10.1 -or later, but you'll need to install the latter from the CPAN. See the -"Test coverage" section above for how you might do that. - -Once the "smoke" target finishes you'll see a message like this: - - TAP Archive created at <path to git>/t/test-results/git-smoke.tar.gz - -To upload the smoke report you need to have curl(1) installed, then -do: - - make smoke_report - -To upload the report anonymously. Hopefully that'll return something -like "Reported #7 added.". - -If you're going to be uploading reports frequently please request a -user account by E-Mailing gitsmoke@v.nix.is. Once you have a username -and password you'll be able to do: - - SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> make smoke_report - -You can also add an additional comment to attach to the report, and/or -a comma separated list of tags: - - SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> \ - SMOKE_COMMENT=<comment> SMOKE_TAGS=<tags> \ - make smoke_report - -Once the report is uploaded it'll be made available at -http://smoke.git.nix.is, here's an overview of Recent Smoke Reports -for Git: - - http://smoke.git.nix.is/app/projects/smoke_reports/1 - -The reports will also be mirrored to GitHub every few hours: - - http://github.com/gitsmoke/smoke-reports - -The Smolder SQLite database is also mirrored and made available for -download: - - http://github.com/gitsmoke/smoke-database - -Note that the database includes hashed (with crypt()) user passwords -and E-Mail addresses. Don't use a valuable password for the smoke -service if you have an account, or an E-Mail address you don't want to -be publicly known. The user accounts are just meant to be convenient -labels, they're not meant to be secure. |