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.

* http://www.objectmentor.com/resources/downloads.html
* http://www.objectmentor.com/resources/bin/CppUnitLite.zip

The motivations for the rewrite:
* More easily write individual tests (one TEST macro which registers the test automatically; instead of method source, header and registration in three different files)
* Follow the JavaUnit model less strictly, avoiding use of LateCeePlusPlus features such as RTTI, exceptions, and templates, thus increasing portability.
** I'm looking for the '''opposite''' myself; I want LateCeePlusPlus features, anything else feels like C...
----
'''Important'''. Error in macro CHECK_EQUAL. When condition is true test stops and no other code is executed.

Revise as following:

    #define CHECK_EQUAL(expected,actual){ if (!((expected) == (actual))) {result_.addFailure(Failure(name_, __FILE__, __LINE__, S''''''tringFrom(expected), S''''''tringFrom(actual))); return; }}
----
I notice that the download only has Visual Studio projects.  How portable is this framework compared to CppUnit?
----

What License is CppUnitLite Distributed under? The downloaded zip file has no license information.

----
There are only the code and a simple example in the package. Are there any documents on how to use CppUnitLite? Or one have to figure it out by herself from the code?

''The book WorkingEffectivelyWithLegacyCode by MichaelFeathers uses CppUnitLite for its CeePlusPlus UnitTest''''''ing examples.''
----
I've got a hacked-up version of CppUnitLite on my website -- http://onesadcookie.is-a-geek.net/svn/repos/CppUnitLite/ (now at http://www.onesadcookie.com/svn/CppUnitLite) -- this version features dots printed to the console in the style of CppUnit, to better show the progress of the tests, and it compiles without warning under very strict GCC warnings settings. --KeithBauer

----

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?

-- AndyGlew

--
Important. Error in macro CHECK_EQUAL. When condition is true test stops and no other code is executed.

Revise as following:

    #define CHECK_EQUAL(expected,actual){ if (!((expected) == (actual))) {result_.addFailure(Failure(name_, __FILE__, __LINE__, S''''''tringFrom(expected), S''''''tringFrom(actual))); return; }}

-- Jakub Kulaviak

----
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

For our trials and tribulations on embedded CppUnitLite see 

M. R. Smith, A. Kwan, A. Martin and J. Miller, "E-TDD -- Embedded Test Driven Development. A Tool for Hardware-Software Co-design Projects", 6th Int. Conf. eXtreme Programming and Agile Processes in Software, pp. 145-153, Sheffield, U.K. June 2005. 

and for our more recent work which extends the framework to include hardware assisted data arace analysis and code coverage within both CppUnit Lite and Embedded UnitTest++ see 

M. R. Smith, J. Miller,  F. Huang and A. Tran, “A case for taking a more ‘Agile’ approach in the development of embedded systems”, IEEE Software Magazine (Special issue on Embedded Software), pp 50 – 57, May 2009. 

-- Mike Smith

----

How does this line of code work:

testGroup##testName##Instance; 

I see testGroup and testName are passed in as parameters and are "token-pasted" or "merged".
Where does Instance come from?  What does it do?

''It's a little difficult to know for certain, since you've left out some important information.  But, assumming that the code looks something like this''

#define MAKE_TEST(testGroup, testName) testGroup##testName##Instance

''Then the following would create the token FooBarInstance''

MAKE_TEST(Foo, Bar)

Thanks. Makes sense now. :)

----
See also CppUnit

CategoryCpp CategoryTesting CategoryFramework