Re: [Boost-Users] Re: how to create fixtures in unit test framework

Since no one has mentioned them yet, there are at least three potential advantages to setUp()/tearDown() over constructors/destructors: 1. If you call virtual member functions from within setUp() and tearDown(), those calls will be serviced by the most derived class. This is useful when some of the setup which varies in derived classes needs to occur before some part of the common setup. 2. The test runner only calls the setUp()/tearDown() method of the most derived class. setUp()/tearDown() in base classes are not called. This is useful when the base and derived classes share a lot of test methods but the setup for the base class is either unnecessary or inappropriate for the derived class. 3. setUp()/tearDown() are called immediately before and after the test method runs. The constructor for a test fixture is typically called when it is added to the test suite which might be long before it is run. That means that the constructor is not an appropriate place to initialize global environmental conditions (eg impersonate another user, or change the working directory). I think Boost.Test users can achieve equivalent functionality by adding their own setUp() and tearDown() methods and then adding: setUp(); shared_ptr<void> guard(static_cast(0), bind(&Class::tearDown, this)); to the top of each test method. To avoid that repetition, Boost.Test users (or the Boost.Test developers) can create/provide a class like boost::unit_test_framework::class_test_case which implements do_run() something like this: // test case implementation void do_run() { if( (!!m_user_test_case) && m_function ) { m_user_test_case->setUp(); shared_ptr<void> guard(static_cast(0), bind(&UserTestCase::tearDown, m_user_test_case)); ((*m_user_test_case).*m_function)(); } } Just my $0.02. --Dean [Non-text portions of this message have been removed]