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

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

Expand Messages
  • Dave Gomboc
    ... 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
    Message 1 of 15 , Sep 1, 2003
    • 0 Attachment
      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?

      Dave
    • 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 2 of 15 , Sep 1, 2003
      • 0 Attachment
        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 3 of 15 , Sep 1, 2003
        • 0 Attachment
          > 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 4 of 15 , Sep 2, 2003
          • 0 Attachment
            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 5 of 15 , Sep 2, 2003
            • 0 Attachment
              ----- 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.