[Cppunit-devel] Pointer ownership problems and other thoughts.

[King D. <Ki...@tc...>]

While trying to figure out how to do some things with CppUnit I have come
across a couple problems with pointer ownership.

I tried using the TestRegistry. Unfortunately it assumes ownership of any
tests that are added to it. That makes it virtually unusable. If I get the
tests from the TestRegistry and add them to a runner, then the runner thinks
it owns them as well and you get an access violation on exit. It appears
that this class is not actually intended to be used as it is not even
included in the MSVC++ project. It appears the intent is to have people use
the TestFactoryRegistry instead and perhaps the TestFactory should be
deleted.

I was also looking at TestDecorator. It seems to have the opposite problem,
that it doesn't take ownership of the test it decorates. It seems to me
either it should take ownership or at least have a way to specify whether it
has ownership the way that TestCaller does. Give me garbage collection over
manual memory management any day.

My goal here is to create a macro that goes along with the helper macros to
define a decorated test. Something like this:

    CPPUNIT_TEST_SUITE( MyTest );
    CPPUNIT_TEST( testEquality );
    CPPUNIT_DECORATED_TEST( testSetName, MyTestDecorator );
    CPPUNIT_TEST_SUITE_END();

The only problem I can see here is that this does not allow you to pass any
parameters to the constructor of the test decorator. For instance with
RepeatedTest it does not allow you to set the number of times to repeat. One
solution is to use templates for decorators and the parameters for the
decorator are passed as template parameters so that you would do a repeated
test like:

    CPPUNIT_DECORATED_TEST( testSetName, RepeatedTest< 5 > );

I've kind of been wondering how others set up their tests. Does everybody
use the helper macros or do they define each test as a different class? I
can see some advantages of the latter as you can define hierarchies where
tests that have common setup can use a common base class where that setup is
done. That is not easy to merge with the macro scheme and autoregistration.
The macros are convenient but limiting sometimes.