-Core GIT Tests
+Core Git Tests
==============
-This directory holds many test scripts for core GIT tools. The
+This directory holds many test scripts for core Git tools. The
first part of this short document describes how to run the tests
and read their output.
be written after every 'git commit' command, and overrides the
'core.commitGraph' setting to true.
+GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=<boolean>, when true, forces
+commit-graph write to compute and write changed path Bloom filters for
+every 'git commit-graph write', as if the `--changed-paths` option was
+passed in.
+
GIT_TEST_FSMONITOR=$PWD/t7519/fsmonitor-all exercises the fsmonitor
code path for utilizing a file system monitor to speed up detecting
new or changed files.
reports "ok" or "not ok" to the end user running the tests. Under
--verbose, they are shown to help debug the tests.
+ - Be careful when you loop
+
+ You may need to verify multiple things in a loop, but the
+ following does not work correctly:
+
+ test_expect_success 'test three things' '
+ for i in one two three
+ do
+ test_something "$i"
+ done &&
+ test_something_else
+ '
+
+ Because the status of the loop itself is the exit status of the
+ test_something in the last round, the loop does not fail when
+ "test_something" for "one" or "two" fails. This is not what you
+ want.
+
+ Instead, you can break out of the loop immediately when you see a
+ failure. Because all test_expect_* snippets are executed inside
+ a function, "return 1" can be used to fail the test immediately
+ upon a failure:
+
+ test_expect_success 'test three things' '
+ for i in one two three
+ do
+ test_something "$i" || return 1
+ done &&
+ test_something_else
+ '
+
+ Note that we still &&-chain the loop to propagate failures from
+ earlier commands.
+
+
And here are the "don'ts:"
- Don't exit() within a <script> part.
As with any programming projects, existing programs are the best
source of the information. However, do _not_ emulate
t0000-basic.sh when writing your tests. The test is special in
-that it tries to validate the very core of GIT. For example, it
+that it tries to validate the very core of Git. For example, it
knows that there will be 256 subdirectories under .git/objects/,
and it knows that the object ID of an empty tree is a certain
40-byte string. This is deliberately done so in t0000-basic.sh
because the things the very basic core test tries to achieve is
-to serve as a basis for people who are changing the GIT internal
+to serve as a basis for people who are changing the Git internals
drastically. For these people, after making certain changes,
not seeing failures from the basic test _is_ a failure. And
-such drastic changes to the core GIT that even changes these
+such drastic changes to the core Git that even changes these
otherwise supposedly stable object IDs should be accompanied by
an update to t0000-basic.sh.
However, other tests that simply rely on basic parts of the core
-GIT working properly should not have that level of intimate
-knowledge of the core GIT internals. If all the test scripts
+Git working properly should not have that level of intimate
+knowledge of the core Git internals. If all the test scripts
hardcoded the object IDs like t0000-basic.sh does, that defeats
the purpose of t0000-basic.sh, which is to isolate that level of
validation in one place. Your test also ends up needing