This is a simple C++ TestingFramework developed by Michael Feathers, who wrote the original CppUnit. Unlike some other frameworks, this one is a barebones framework intended to be extended by its users to support their particular needs.

AndyGlew: (these are notes as I am looking to upgrade my test infrastructure; I haven't actually used CppUnitLite at the time I write this, although I have read all of the code):

Overall, it looks like CppUnitLite uses mild macro trickery, so that TEST(testName,testgroup)
creates a test class, but also creates an object that registers itself with a singleton registry,
which can then run all the tests. I expect that it reduces some of the drudgery of
writing tests in C++.

It's not clear to me that CppUnitLite eliminates all of the drudgery,
or whether it is still necessary to have some external Perl scripting.
For example, here is a standard test for a C++ header file: in file
header_test_foo.cpp:

#include <foo.hpp>
#include <foo.hpp>
main() {}

I.e. this is a completely standalone test executable, that tests that the header file
foo.hpp (a) includes everything it depends on, and (b) is appropriately guarded
so that it can be included twice.

Many C++ folk automatically generate something like this test using Perl scripts or the like.
I don't think that CppUnitLite eliminates the need.

CppUnitLite looks like it will test all classes that are linked into an executable.
This probably means that you still have to have something in your build tool that
produces the executable, something like

TESTS=*.cpp
test: $(TESTS)
gcc -o test test-main.cpp $(TESTS)
./test

That's pretty trivial; fancier stuff will still need Perl scripts.

Q: if you need Perl scripts anyway, maybe the Perl scripts should avoid the need
for the macro trickery of CppUnitLite?

We have successfully ported Cpp Unit Lite to a number of embedded systems within the Analog Devices processor family including single core Blackfin BF533, multi-core Blackfin BF561 and multi-processor systems TigerSHARC 201. The main advantage of CPP Unit Lite over running perl scripts is that talking to embedded system under test using a JTAG interface to transmit the (perl-based) tests takes 10's of milli-seconds while you can run CPPUnitLite directly within the core of the embedded system without penalizing processor performance. We even were able to make use of a background telemetry channel (BTC) as an alternative I/O path to optimize the reporting of the extremely rare errors ( :-) ) we introduce into our code.

More recently we have gone over to using UnitTest++ which uses essentially the same syntax as CppUnitLite but is much richer in features. This move has been a success for embedded systems with a large enough external memory to store the code. CppUnitLite Tests (and library) used to fit nicely into the internal memory of the Blackfin. We have had CppUnit Lite and UnitTest++ running on Analog Devices Blackfin and TigerSHARC processors, T.I. C64XX processors and MIPS -- with the TI and Analog Devices variant having a lot of hardware assisted extensions appropriate for the new embedded environment