Interesting, that's actually not how I run the tests. I run the tests just by invoking the runner itself:

./libgit2_clar

in the build output directory. Instructing people to do it this way gives them some amount of control over how the tests get run. For example, we could also tell them that they can run a specific test with:

./libgit2_clar -score::string::strcasecmp

or use a prefix to match only some of the tests, like:

./libgit2_clar -score

Then again, this may be unnecessarily detailed for people. Some people are just running the tests to make sure that their compiled binary works, not because they're hacking on the code. What do you think?

Yes, I'm not sure, there are other tests besides libgit2_clar though? Could always add another paragraph saying something like, "you can also run the tests directly with ./libgit2_...." ?

Yes, I'm not sure, there are other tests besides libgit2_clar though?

No - libgit2_clar is the entirety of our tests, it is the test runner and tests compiled into a single executable. When you run make test, it simply invokes libgit2_clar for you.

My suggestion is that giving people more insight into the test runner is a valuable thing... I also think that it's more memorable (than the magic variable needed to emit test output).

I wonder if there's a way to make CTEST_OUTPUT_ON_FAILURE=1 the default so that it doesn't need to be specified on the command line? That would make the make test suggestion much more compelling for users, I think.

Ah right, I don't really have a preference here, though I agree that having to specify CTEST_OUTPUT_ON_FAILURE=1 is less memorable. I'll see if there's a way to make it the default.

After working with the tests a bit more I think it's probably useful for people to know how to run the tool directly, since that allows you to specify individual tests, which, if you're working on the test set, saves time. So I'll modify this to include how to do that.

I've reworked this to express both ways of running tests, as far as outputting failure by default goes, I don't really know cmake at all but one simple method seems to be to add a custom target, e.g.

add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} --output-on-failure)

then you run the tests with make check

Cool, thanks, I think this will help people get started! 😀