Now that we have two types of object IDs, with different sizes, we expect shorter object ID types (in other words, SHA1 object ids) to be zero-padded at their suffix. This allows us to use faster comparison and copy routines over the entirety of the structure, instead of trying to examine the type and then do a comparison of the appropriately sized structure. For pure manipulation of object IDs, this produces parity with the SHA1-only object ID code. SHA1: oid::cmp_sha1: 8.065 ms ± 703.9 μs / range: 7.875 ms … 14.88 ms (201 runs) oid::cmp_sha256: skipped oid::cpy_sha1: 5.340 ms ± 47.26 μs / range: 5.272 ms … 5.617 ms (548 runs) oid::cpy_sha256: skipped oid::zero_sha1: 5.327 ms ± 49.27 μs / range: 5.271 ms … 5.612 ms (553 runs) oid::zero_sha256: skipped SHA256 (before this change; testing the `type`): oid::cmp_sha1: 10.82 ms ± 1.029 ms / range: 10.57 ms … 20.63 ms (145 runs) oid::cmp_sha256: 10.63 ms ± 103.9 μs / range: 10.50 ms … 11.48 ms (279 runs) oid::cpy_sha1: 26.13 ms ± 63.91 μs / range: 26.07 ms … 26.45 ms (113 runs) oid::cpy_sha256: 20.92 ms ± 58.32 μs / range: 20.86 ms … 21.25 ms (141 runs) oid::zero_sha1: 13.19 ms ± 129.1 μs / range: 13.11 ms … 13.72 ms (224 runs) oid::zero_sha256: 13.12 ms ± 30.06 μs / range: 13.10 ms … 13.30 ms (225 runs) SHA256 (with this change): oid::cmp_sha1: 7.985 ms ± 562.3 μs / range: 7.874 ms … 14.32 ms (209 runs) oid::cmp_sha256: 6.609 ms ± 30.77 μs / range: 6.584 ms … 6.870 ms (443 runs) oid::cpy_sha1: 5.282 ms ± 21.90 μs / range: 5.266 ms … 5.524 ms (543 runs) oid::cpy_sha256: 5.279 ms ± 17.57 μs / range: 5.263 ms … 5.415 ms (554 runs) oid::zero_sha1: 5.288 ms ± 22.92 μs / range: 5.268 ms … 5.508 ms (544 runs) oid::zero_sha256: 5.286 ms ± 21.29 μs / range: 5.271 ms … 5.527 ms (542 runs)
libgit2 tests
These are the unit and integration tests for the libgit2 projects.
headertest
This is a simple project that ensures that our public headers are compatible with extremely strict compilation options.libgit2
These tests exercise the core git functionality in libgit2 itself.resources
These are the resources for the tests, including files and git repositories.util
These are tests of the common utility library.
Writing tests for libgit2
libgit2 uses the clar test framework, a C testing framework.
The best resources for learning clar are clar itself and the existing tests within libgit2. In general:
-
If you place a
.cfile into a test directory, it is eligible to contain test cases. -
The function name for your test is important; test function names begin with
test_, followed by the folder path (underscore separated), two underscores as a delimiter, then the test name. For example, a filemerge/analysis.cmay contain a testuptodate:void test_merge_analysis__uptodate(void) { ... } -
You can run an individual test by passing
-sto the test runner. Tests are referred to by their function names; for example, the functiontest_merge_analysis__uptodateis referred to asmerge::analysis::uptodate. To run only that function you can use the-soption on the test runner:libgit2_tests -smerge::analysis::uptodate
Memory leak checking
These are automatically run as part of CI, but if you want to check locally:
Linux
Uses valgrind:
$ cmake -DBUILD_TESTS=ON -DVALGRIND=ON ..
$ cmake --build .
$ valgrind --leak-check=full --show-reachable=yes --num-callers=50 --suppressions=../libgit2_tests.supp \
./libgit2_tests
macOS
Uses leaks, which requires XCode installed:
$ MallocStackLogging=1 MallocScribble=1 MallocLogFile=/dev/null CLAR_AT_EXIT="leaks -quiet \$PPID" \
./libgit2_tests
Windows
Build with the WIN32_LEAKCHECK option:
$ cmake -DBUILD_TESTS=ON -DWIN32_LEAKCHECK=ON ..
$ cmake --build .
$ ./libgit2_tests