Hash :
7f53d7b6
Author :
Date :
2022-05-09T12:09:08
revparse: Remove error-prone, redundant test Originally introduced in: 776a6a8e5f8e258d31aded73c0ce38df6ac7bdc4 This test case has recently been fixed in bdab22384cc61d315005a65456a9f9563bb27c8f, but that fix will only last for a year. Next year the same problem will crop up and the test will need to be re-edited. This is not ideal as - This test case becomes an unnecessary burden for developers - Downstream distros or even just users who want to build older versions of libgit2 are guaranteed to have this test fail Furthermore, this test case is entirely unnecessary, as the functionality that was originally (see 776a6a8e5f8e258d31aded73c0ce38df6ac7bdc4) intended to be tested is well-covered by subsequent tests which specify a date instead of a "x ago" specification.
Git HTTP | https://git.kmx.io/thodg/libgit2.git |
---|---|
Git SSH | git@git.kmx.io:thodg/libgit2.git |
Public access ? | public |
Description | |
Users |
![]() |
Tags |
|
These are the unit and integration tests for the libgit2 projects.
benchmarks
These are benchmark tests that excercise the CLI. clar
headertest
libgit2
resources
util
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
These are automatically run as part of CI, but if you want to check locally:
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
Uses leaks
, which requires XCode installed:
$ MallocStackLogging=1 MallocScribble=1 MallocLogFile=/dev/null CLAR_AT_EXIT="leaks -quiet \$PPID" \
./libgit2_tests
Build with the WIN32_LEAKCHECK
option:
$ cmake -DBUILD_TESTS=ON -DWIN32_LEAKCHECK=ON ..
$ cmake --build .
$ ./libgit2_tests