Multi-instance test in CppUnit

  • Ofri Sadowsky

    Ofri Sadowsky - 2003-06-20

    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.

    • Anthon Pang

      Anthon Pang - 2003-07-08

      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.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks