Loading ...
Sorry, an error occurred while loading the content.
 

Re: Re: how to create fixtures in unit test framework

Expand Messages
  • Anders Moe
    On Mon, 1 Sep 2003 07:27:28 -0600 (MDT), Dave Gomboc ... If you mean RAII in each test method that is somewhat laborious and error prone
    Message 1 of 15 , Sep 1, 2003
      On Mon, 1 Sep 2003 07:27:28 -0600 (MDT), Dave Gomboc <dave@...>
      wrote:

      > On Mon, 1 Sep 2003, Anders Moe wrote:
      >
      >> Having given some thought to this during the weekend I have also
      >> realized a significant difference between ctor/dtor and setup/teardown,
      >> as was posted in another subthread of this thread, namely this :
      >>
      >> 1) the ctor(s) is called at test _setup_ time, while the setup(s) is
      >> called at test _runtime_
      >> 2) the dtor(s) is called at test suite exit time, while the teardown(s)
      >> is called, again, at test runtime.
      >
      > I may just be missing something, I've been up all night :-), but it's not
      > obvious to me why one cannot accomplish setup/teardown by appropriate use
      > of RAII. Could someone post a concrete example?
      >
      If you mean RAII in each test method that is somewhat laborious and error
      prone - the nice
      thing about overloading setup/teardown is that the framework does the
      calling. If you mean the ctor/dtor version of setup/teardown I was hoping
      my previous post would provide
      some arguments.

      Anders.
    • Dave Gomboc
      ... I still don t see big disadvantages to RAII. I guess I ll continue on in ignorance for the moment. :-/ Dave
      Message 2 of 15 , Sep 1, 2003
        > If you mean RAII in each test method that is somewhat laborious and error
        > prone - the nice
        > thing about overloading setup/teardown is that the framework does the
        > calling. If you mean the ctor/dtor version of setup/teardown I was hoping
        > my previous post would provide
        > some arguments.

        I still don't see big disadvantages to RAII. I guess I'll continue on in
        ignorance for the moment. :-/

        Dave
      • Steve Hutton
        In article , ... What about using containment instead then, if you only want to share test method
        Message 3 of 15 , Sep 2, 2003
          In article <024001c36f45$8180bbf0$04fda8c0@...>,
          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?

          > 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/

          Steve
        • Dean Brettle
          ... From: Steve Hutton To: boost-users@yahoogroups.com Sent: Tuesday, September 02, 2003 6:32 PM Subject: [Boost-Users] Re: how to create fixtures in unit test
          Message 4 of 15 , Sep 2, 2003
            ----- Original Message -----
            From: Steve Hutton
            To: boost-users@yahoogroups.com
            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@...>,
            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]
          Your message has been successfully submitted and would be delivered to recipients shortly.