The exercise ConsiderationsForAndComparisonOfCeePlusPlusTestFrameworks
helped me understand what I did not like about CppUnit.

First, I must admit that CppUnit has greatly improved
over the last few years.  It used to require far more redundant
typing than it does now.  Nevertheless, I think it still
has problems.

Mainly, CppUnit requires redundant typing.  A test case must be
defined as a fixture in a method, and then linked into a suite.
It does not have a TestCollector script.

CppUnit has been extended with macros that reduce
some, but not all, of this redundant typing.
However, these macros are non-syntactic C++ macros,
a code smell in and of themselves.

I think the fundamental problem is that CppUnit
structures test cases as methods of a fixture,
and then binds the method to create an independent test case
object.
     class ComplexNumberTest ...
         void testEquality() { ...
     };
     
     CppUnit::T''''''estCaller?<ComplexNumberTest> 
	test( "testEquality",
		&ComplexNumberTest::testEquality );

This requires redundant typing that cannot be completely
hidden by macros, and which is hard to handle in simplistic
TestCollector scripts that do not understand C++,
e.g. that work line by line.

I think it is semantically equivalent,
and much more conducive to simple TestCollector scripts,
to express test cases as void functions or classes
with a test() method, where the test fixture is
inherited by the test case.

-----

It could also use VC++ itself as the test runner. See VisualCeePlusPlus.

----

See StarUnitAutoSuite.

----
CategoryCpp CategoryTesting