If anyone is interested, I have a class for running multiple instances of a test case. I attach a brief explanation about the motivation and implementation of the class. I would be useful, though, to add or change the helper macros so that it will be possible to obtain a factory function for a single case (that is, a single member function) of a CppUnit::TestCase.
I send copies of this message to the Feature Requests tracker and to the discussion forum. Please make contact if you're interested in more details.
\brief Create and run multiple instances of the same test case.
Class tstMultiInstanceTest extends the CppUnit::Test class by adding
the option to create and run multiple instances of the same test case.
This feature is useful, for example, when we want to add randomization
to our test fixture. Consider the case of a test fixture that creates
randomly-parametrized objects on instantiation, and then tests these
objects using random input, which is determined at the setUp() phase.
We want to repeat the ranodmized test a large number of times, and for
a large set of random instances. But currently, CppUnit::RepeatedTest
only enables to test a single instance multiple times, and does not
consider multiple instances. Our class is made to handle this case.
A tstMultiInstanceTest is initialized with a factory function which
creates CppUnit::Test objects, and returns their address. We can
change the number of instances at any time using the SetNumInstances()
method. The instances are stored in a std::vector, and SetNumInstances()
adds new test-case instances to the back of the vector, or removes them
from there if we want to reduce the number of instances.
I'd be interested in seeing this. I've been thinking about how best to write data-driven tests in cppunit Data sources might include an array of structures (containing inputs and expected results), external files (e.g., CSV or XML), a database table, etc.
Ideally, such a loop would be outside of the test fixture.
Some thoughts on requirements: (a) pass a number (representing the instance/iteration) to each of the test object, (b) provide additional assert (or utility) macros that take this instance number as a parameter, and (c) consider the possibility that the number of iterations may not be known in advance.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.