Files
libgit2/tests
Patrick Steinhardt 4686f10ecb refs: introduce GIT_HEAD_REF define
Introduce the GIT_HEAD_REF define so that we can clearly indicate that
we're talking about the "HEAD" reference and not necessarily a file.
Note that there still are a couple of places where GIT_HEAD_FILE is
being used:

  - `git_repository_create_head()`: This function is used to create HEAD
    when initializing a new repository. This should get fixed eventually
    so that we create HEAD via the refdb, but this is a more involved
    refactoring that will be handled in a separate patch series.

  - `repo_init_head()`: Likewise.

  - `conditional_match_onbranch()`: This function is used to decide
    whether or not an `includeIf.onbranch` condition matches. This will
    be fixed in subsequent commits.

Other than that there shouldn't be any more references to GIT_HEAD_FILE.
2025-12-08 07:27:24 +01:00
..
2025-01-23 10:32:52 +00:00
2025-03-29 18:16:45 +11:00
2022-02-27 23:44:19 -05:00

libgit2 tests

These are the unit and integration tests for the libgit2 projects.

  • benchmarks These are benchmark tests that excercise the CLI.
  • clar
    This is clar the common test framework.
  • 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 .c file 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 file merge/analysis.c may contain a test uptodate:

    void test_merge_analysis__uptodate(void)
    {
      ...
    }
    
  • You can run an individual test by passing -s to the test runner. Tests are referred to by their function names; for example, the function test_merge_analysis__uptodate is referred to as merge::analysis::uptodate. To run only that function you can use the -s option 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