Re: [Cppunit-devel] hierarchy sample bug...
Brought to you by:
blep
Menu
▾
▴
Re: [Cppunit-devel] hierarchy sample bug...
|
From: Bastiaan B. <bas...@li...> - 2001-05-08 00:15:54
|
Baptiste Lepilleur wrote:
> > Humm, just one thing that popup in my mind: who owns the fixture given
> > to the test caller ? That's may be the reason why it is done that way...
> >
> > I guess it had something to do with the automatic test registration thing,
> > which has been removed anyway.
> No, it was done that way in Michael Feather version. And if I understood
> thing well, it's also done that way in junit.
>
Not!
Please take a look at the JUnit code. JUnit doesn't have a TestCaller: it doesn't need one because it can use Java Reflection to lookup test methods and execute them.
Also, the only container for Tests is the TestSuite class, no Registries or other things.
It's simple and I like it.
>
> > Because I did not have a clear picture of all use cases of TestCaller, the
> > current implementation allows the TestCaller to own the Fixture or not:
> > If the Fixture is passed through a reference the TestCaller won't own it.
> > If the Fixture is passed through a pointer the TestCaller will assume
> > ownership and destroy it in its destructor.
>
> Things I want to point out:
> - in about 95% of the case, you use the default constructor for the
> fixture.
> - Even when subclassing a test case, you override the setUp() and
> tearOff() method, and would still have a default constructor.
> - non default constructor would most likely be used for a test case with
> are parameterized (a generic test case that load tests from a file for
> example). I don't see that happening often. And in all likelyhood, you would
> more likely overide runTests() than create a suite using some test
> callers...
The main problem is not that the old TestCaller uses the default constructor, but that it is creating the wrong (base) class.
>
> Well, here I presents the test cases of use of the TestCaller.
>
> The common code to create a suite is as follow:
>
> TestSuite *suite = new TestSuite( "MyTestCase" );
> registerTest( suite );
>
> void registerTest( TestSuite *suite )
> {
> suite->addTest( new TestCaller<MyTestCase>( "test1", test1 ) );
> suite->addTest( new TestCaller<MyTestCase>( "test1", test2 ) );
> ...
> }
>
> Using the constructor with a pointer on the fixture works:
> void registerTest( TestSuite *suite )
> {
>
> te->addTest(
> new TestCaller<MyTestCase>( "test1", test1,
> new MyTestCase( "file-test1.test") ) );
>
> suite->addTest(
> new TestCaller<MyTestCase>( "test1", test2,
> new MyTestCase("file-test2.test") ) );
> ...
> }
>
> The problem is if you want one fixture to be shared with many test caller (which is what you would do when subclassing and reusing test case):
>
> void registerTest( TestSuite *suite, MyTestCase &fixture )
> {
> suite->addTest(
> new TestCaller<MyTestCase>( "test1", test1, fixture ) );
> suite->addTest(
> new TestCaller<MyTestCase>( "test1", test2, fixture ) );
> ...
> }
>
> The problem is who owns the referenced fixture:
>
> MySubclassedTestCase::suite() {
> TestSuite *suite = new TestSuite( "MySubClassedTestCase" );
>
> // WHO owns that fixture ??? => who will delete it ?
> MySubclassedTestCase *fixture = new MySubclassedTestCase();
> MyTestCase::registerTest( suite, *fixture );
> ...
> }
>
> As I see it the problem is solved by introducing a makeFixture() virtual method in test case which can be subclassed. You would have something like:
>
> void registerTest( TestSuite *suite )
> {
> suite->addTest(
> new TestCaller<MyTestCase>( "test1", test1, makeFixture() ) );
> suite->addTest(
> new TestCaller<MyTestCase>( "test1", test2, makeFixture() ) );
> ...
> }
>
Sorry to be blunt, but I think this sucks, because you need to be very careful to override makeFixture() in every subclass. Why can't the TestCase use a reference to itself instead?
>
> So until a clean way is found to "share" a fixture between test callers, I'll stick to the one fixture per test caller policy (not that much of a bother after all). All the previous problem (subclassing) have been solved by the introduction constructor with a pointer on the fixture.
>
Ahem, the amended 'hierarchy' example seems like a perfectly valid example of how to use the same fixture for multiple TestCallers. Any objections?
>
> The only use I can see for the test caller with fixture by reference is if the Test Caller is stored by value in another class.
>
> Things to do:
> Update TestSuiteBuilder:
> - add a addTestCaller() method which take a pointer on the fixture.
> - a
> dd a constructor that take a pointer on a "makeFixture()" methods, to make
> subclassing easier.
>
Before you rush off to add makeFixture() methods, etc. Let us rethink this issue a bit. My personal feeling is that this registration stuff already is more complex than necessary, so adding more stuff is unlikely to be the proper solution. I prefer to steal more from JUnit :-)
>
> Baptiste.
>
> PS: I tried to login with CVS and SSH this afternoon and I got a error
> message. So I guess I'll have to go back to the doc ;-(
I don't know when you tried it, but note that there is a 6(?) hour delay in propagation of the project membership. Your project membership may simply not have reached the CVS server at that time.
Please try it again. Also check if you can get shell access with SSH on cppunit.sourceforge.net.
Bastiaan
>
> ---
> Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html
> Author of The Text Reformatter, a tool for fanfiction readers and writers.
> Language: English, French (Well, I'm French).
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
|
