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

From: Dean Brettle (dean_at_[hidden])
Date: 2003-09-02 23:05:05

  ----- Original Message ----- 
  From: Steve Hutton 
  To: boost-users_at_[hidden] 
  Sent: Tuesday, September 02, 2003 6:32 PM
  Subject: [Boost-Users] Re: how to create fixtures in unit test framework

  In article <024001c36f45$8180bbf0$04fda8c0_at_[hidden]>,
  Dean Brettle wrote:
  > 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.
  > 

  What about using containment instead then, if you only want to
  share test method implementations, but not the construction/
  destruction?

By containment do you mean:

class TestMethods
{
  void testMethod1();
  void testMethod2();
};

class TestFixtureA
{
  TestMethods m_methods;
  void testMethod1() { m_methods->testMethod1(); }
  void testMethod2() { m_methods->testMethod2(); }
};

class TestFixtureB
{
  TestMethods m_methods;
  void testMethod1() { m_methods->testMethod1(); }
  void testMethod2() { m_methods->testMethod2(); }
};

If so, I certainly agree that is an option.  I just find it tedious to delegate each test method in these sort of situations.  Or put another way, I consider it a valuable feature of CppUnit that I don't have to do such delegation.

  > 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).
  > 

  It may be that the test fixture constructors are called ahead of
  time in some designs, but that doesn't have to be the case.  For
  example, TUT does not do it that way.
  http://tut.dozen.ru/design/

Understood.  I should have said that I was specifically comparing CppUnit (and the other xUnits derivatives, I think) to Boost.Test in this regard.  

--Dean

[Non-text portions of this message have been removed]