The same as in lightgrep:

• https://github.com/strozfriedberg/lightgrep/blob/main/configure.ac#L316
• https://github.com/strozfriedberg/lightgrep/blob/main/Makefile.am#L342

Tests are in `test/.

Hmm. It looks like nothing is ensuring cppunit is there in CI. Given that we aim to stop using it immanently, it's a waste of time to get cppunit working.

I'll switch #1057 over to Catch2 next.

If you look in unit_tests/ in develop, you'll see that there are a total of three tests using cppunit, none of which test anything of substance in Sleuthkit. The conclusion I reached from this is that someone set up cppunit about 15 years ago and then didn't use it.

I.e., we should stop using cppunit before anyone seriously starts using it.

If there is a significant reason to move to catch, we can do that. But right now I want to concentrate on new stuff. Is there a serous reason to avoid cppunit?

Given that we're starting from close to zero with unit tests, we should chose the best test framework we can.

I rarely encounter projects using cppunit these days. It's unpleasant to work with. I'm not enthusiastic about writing tests with it and I expect other people who might contribute tests would feel the same way.

Catch2 is pleasant to use. We've both had good experiences with it. I'm volunteering to set it up. Catch2 has support for test order randomization, which helps flush out otherwise hard to find bugs; test sharding, so we can easily parallelize tests; and benchmarking, which could help us make Sleuthkit faster. I've used all these features and would miss them in cppunit.

Writing new tests with cppunit when we aim eventually to convert to Catch2 is wasting all the time we will spend converting those tests. We could write them in the better framework from the start and spend less time doing it.

All of our internal projects are already using v3. I'd prefer to avoid migrating altogether and start with v3 (which is what I've done already in the PR).

Do you prefer v3 to be embedded directly, or to be a submodule, or to be separately installed?

Internally, our overall CI framework builds Catch2. For CI here, I'm not sure yet what will be simplest. I'll look into options for that next. (Not until mid-week, though. I'm away for the next few days.)

If we can get it as a package, that saves us from needing to build it. That's the best approach. I'm glad it works.

It works. I hard-coded the cppunit to make it work on homebrew, but I'm eager to get rid of it. It's all yours now.
Once you have catch deployed (I guess we are going with catch2, since catch3 is under devel still), I'll take a closer look at the codecov mess.