Hi again and thanks for your reply. If I understand you correctly you suggest using the ctor/dtor in the class-test-case to do the job of build_up/tear_down. I suppose that would be equivalent to setup/teardown. This works, ofcourse, because a C++ programmer can rely on the dtor being executed, unlike the Java finalizer. Anders. "Gennadiy E. Rozental" <rogeeff@mail.com> wrote in message news:bime6h+fbbu@eGroups.com...

...

Hi all. The boost unit test framework seems to lack the xUnit buildUp/tearDown (whatever) methods meant to faciliate the creation of fixtures. Does that mean there is an alternative idiom to achieve

--- In Boost-Users@yahoogroups.com, "Anders Moe" <yg-boost- users@m...> wrote: the same

...

effect ? Constructing new class-test-cases for each test seems a bit overkill.

Regards,

Anders.

No. At the moment there is no explicit notion of buildUp and TearDown methods. In in my list of things to consider. I am not sure we really need that. Could you provide an example of what and when should be done inside these function. If you just need a place to initialize set of test cases that share some data, you could at the moment use user test class based test cases. You create and initialize single instanse of test class and test cases are methods of that class. The instance will be shared and destroyed when testing is done.

HTH,

Gennadiy.

Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--- At Fri, 29 Aug 2003 11:02:51 +0200, Anders Moe wrote:

...

Hi again and thanks for your reply.

If I understand you correctly you suggest using the ctor/dtor in

...

class-test-case to do the job of build_up/tear_down. I suppose

--- In Boost-Users@yahoogroups.com, "Duane Murphy" <duanemurphy@m...> wrote: the that would be

...

equivalent to setup/teardown. This works, ofcourse, because a C++ programmer can rely on the dtor being executed, unlike the Java finalizer.

Having worked some with CppUnit, I have wondered similarly.

It's hard to judge when a particular "feature" is put in to work around

Did you try to use Boost.Test? Any comparison? limitations or

differences in the language. When I studied JUnit, I didnt fully grasp the need for setUp and tearDown. This explaination makes some sense.

Do you mean, that in C++ we do not need explicit teardown and buildup?

The equivalent is simply member variables or something similar in C++.

I did not get this. An equivalent to what?

...Duane

Gennadiy.

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<void*>(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<void*>(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]

----- 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.dev.omniva.com>, 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]

...

If I understand you correctly you suggest using the ctor/dtor in the class-test-case to do the job of build_up/tear_down. I suppose that would be equivalent to setup/teardown. This works, ofcourse, because a C++ programmer can rely on the dtor being executed, unlike the Java finalizer.

Anders.

Does that mean that my answer sattisfy your need in bringup/teardown functionality? Do you think it is going to be acceptable always?

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. This makes a real difference when, say, setup acquires a unique resource : boost_shared_ptr<Test1> (new Test1); // ctor called, open log file log.txt suite->add_test_case (<some Test1 method) suite->add_test_case (<some Test1 method) suite->add_test_case (<some Test1 method) boost_shared_ptr<Test1> (new Test2); // ctor called, open log file log.txt...FAILURE, already open suite->add_test_case (<some Test2 method) suite->add_test_case (<some Test2 method) suite->add_test_case (<some Test2 method) If instead log.txt was opened/closed in setup/teardown, the test methods called in between would work just fine. Anders Moe.

On Mon, 1 Sep 2003 07:27:28 -0600 (MDT), Dave Gomboc <dave@cs.ualberta.ca> 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.