Hello. In September there was a discussion of how to set up text fixtures for unit tests and the relative merits of a setUp() tearDown() method. A key issue that I did not see included in this discussion is how setUp() affects the sharing of the test fixture between methods in a test class. For example, let's say your fixture includes the setup of an object myA as part of its fixture:

class TestFixtureA
{
  MyA myA;
  TestFixtureA(...) : myA(...){  }
  void testMethod1() { perturbWithMethod1(myA);
                      
BOOST_CHECK(somethingAbout(myA)); }
  void testMethod2() { perturbWithMethod2(myA);
                      
BOOST_CHECK(somethingElseAbout(myA); }
};

The results of testMethod2 are context sensitive: if you include testMethod1 and testMethod2 in your suite, the results of testMethod2 can be different than if testMethod2 were called alone. This seems to take the unit out of unit testing, and the fix out of fixture. In other frameworks, the behavior is that setUp() will be called independently for each invocation of each test method. This is possibly resource intensive, but makes for very atomic testing and I think it is essential to the unit testing concept.

In Boost.Test, this sort of stable fixture can be obtained via Dean Brettles suggestion by defining a setUp function in the test class:

setUp();
shared_ptr<void> guard(static_cast<void*>(0),
bind(&Class::tearDown, this));

and calling this function from every other single test function. This is a pain to do manually, and introduces human error issues. Dean included a second suggestion as to how to make it part of the framework.

I would like to second the suggestion. I feel the constructor based approach in Boost is excellent for parts of the fixture that are shared for whatever reason. The framework would be more flexible, however, if the setUp() existed to assure stable values over a test suite.

Thanks for listening,
Eli