Thread: RE: [Cppunit-devel] hierarchy sample bug...
Brought to you by:
blep
Menu
▾
▴
cppunit-devel
|
From: Bastiaan B. <bas...@li...> - 2001-05-07 09:06:30
|
-----Oorspronkelijk bericht-----
Van: Baptiste Lepilleur [mailto:bl...@cl...]
Verzonden: Sunday, May 06, 2001 2:12 PM
Aan: cpp...@li...
Onderwerp: Re: [Cppunit-devel] hierarchy sample bug...
--8<--
> That is correct behaviour. The BoardGameTest checks invariants that should
hold
> for all BoardGameTest instances, including Chess objects. The testReset()
> method in BoardGameTest should equally apply to Chess objects. Overriding
> testReset() in ChessTest is a serious indication that the design of
application
> is flawed.
I agree with that. Though in some case you might have some "template
method" (the pattern) in your test case. I can see that applying when you
have some specific behavior and want to factor some testing part. An example
that pop up into my mind would be testing visitor/strategy/builder. The
setup of each test may be identical and you would want to factor out those
part in a base class. Then, you would use the self-shunt pattern (having the
test case implementing the visitor interface...), and delegate part of the
actual test to the derived test case.
OK, you got me there! :-)
> However, there is one problem, which may be what you hint at: the current
> BoardGameTest implementation implies that all BoardGame classes have a
default
> constructor and need no further setup.
This is indeed the main problem I see. You want the setUp() and
tearOff() method of your derived class to be called: initialization of the
"game" class, initialization of the default database connection for the
current thread...
I've implemented the fix I suggested yesterday: TestCaller now has two extra
constructors which accept either a reference or a pointer to an existing
fixture as an extra parameter. Now GameBoardTest constructs a TestCaller
with *this as Fixture and the correct setUp(), tearDown() and testmethod are
called.
I don't see why every TestCaller needs its own Fixture instance, so if there
aren't any objections I'd like to deprecate the old constructor.
Please let me know if you see any flaws in this approach.
Bastiaan
Baptiste.
---
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
|
|
From: Bastiaan B. <bas...@li...> - 2001-05-07 11:28:02
|
-----Oorspronkelijk bericht-----
Van: Baptiste Lepilleur [mailto:bl...@cl...]
Verzonden: Monday, May 07, 2001 12:13 PM
Aan: cpp...@li...
Onderwerp: Re: [Cppunit-devel] hierarchy sample bug...
> I've implemented the fix I suggested yesterday: TestCaller now has two
extra
> constructors which accept either a reference or a pointer to an existing
> fixture as an extra parameter. Now GameBoardTest constructs a TestCaller
> with *this as Fixture and the correct setUp(), tearDown() and testmethod
are
> called.
> I don't see why every TestCaller needs its own Fixture instance, so if
there
> aren't any objections I'd like to deprecate the old constructor.
> Please let me know if you see any flaws in this approach.
I would let the old constructor alone, but indicates in the
documentation that the new one should be used instead.
Since the old constructor leads to broken behaviour, I would like to mark it
deprecated in 1.5.5 and remove it eventually. This implies that at least the
code in CppUnit itself will not use this constructor anymore. Could you
please look into how to do this for the code merged from CppUnitW?
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.
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.
As far as I can see we won't need the second variant.
Bastiaan
>
> Bastiaan
>
>
> Baptiste.
> ---
> 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
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
http://lists.sourceforge.net/lists/listinfo/cppunit-devel
|
|
From: Baptiste L. <bl...@cl...> - 2001-05-07 19:16:37
|
> 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.
> 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...
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() ) );
...
}
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.
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.
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 ;-(
---
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).
|
|
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
|
|
From: Baptiste L. <bl...@cl...> - 2001-05-08 11:21:09
|
> > > 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.
They don't have a test caller class because the test caller is the test
case itself. Here is a piece of code extracted from
TestSuite.addTestMethod() (called for each public test method on
construction):
if (isPublicTestMethod(m)) {
names.addElement(name);
Object[] args= new Object[]{name};
try {
addTest((Test)constructor.newInstance(args)); // <=== a new
instance is created which take the name of the method in the constructor !
} catch (Exception t) {
addTest(warning("Cannot instantiate test case: "+name));
}
and in TestCase.runTest() that do what our test caller is doing:
// fname is the name specified on construction of the test case, the name of
the method to run!
runMethod= getClass().getMethod(fName, new Class[0]);
[...]
try {
runMethod.invoke(this, new Class[0]);
}
This exactly what our test caller do... In some way we have even more
flexibility because we can decorate the test caller (adding running time
constraint, expecting some exception...).
>
>
> >
> > > 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.
I'm ok with that.
> > 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?
Its depends how you make your code. I use IDE macro to generate and adds
file to the project. I just check a box to say "this class is a cppunit
test case", and it adds everything I need to make the class a test case
(static suite method, inheritance, includes...). This way I remove all the
problem you have when using cut and paste to do that.
> Ahem, the amended 'hierarchy' example seems like a perfectly valid example
of how to use the same fixture for multiple TestCallers. Any objections?
There is a very bad thing about the way its done: you enforce the class
owning the test caller to also own a reference to the test case. Any class
you give the test caller to, must also own the instance of the test case
that was used to create the test caller.
To me this is a big loss of flexibility. It makes it harder to use stuff
such as decorator and break the "ownership" policy that is everywhere in the
framework:
TestSuite owns all its tests (sub-suite, TestCaller, ...)
TestCaller owns all its TestCase
TestCase owns resources needed to run the test.
Each component of the hierarchy can be taken out of the system and works
on its one. The TestCaller does not need the TestSuite to be able to run.
Usually, you don't build test case on the stack. You have a static
suite() method in the test case returning a new TestSuite object. With the
new ownership policy, you would have to subclass TestSuite so it could hold
(and own) a reference on the TestCase instance.
To sum it up:
- the TestCaller would not be able to be a component running on its one
(you could not pass it to the TestRunner because it need something "above"
owning the test case).
- you provided a valid example of use of the test caller with a
reference on the test case. Though there are underlying constraints to that
use case (at suite level).
- this would break one of the constructor of TestSuiteBuilder since it
could not use the generic TestSuite class, but would need to instantiate its
owns subclassed TestSuite.
Sharing the reference on the test case does not make it easier to use,
and split from the ownership policy that is in the framework. Using the
standard template factory method pattern (makeFixture()) seems a lot easier
to me and much more flexible.
>
> >
> > 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.
> > - add 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 :-)
I was not suggesting adding the makeFixture() method in the library.
This is a user choice (just like having a registerTests() method). If the
user make a test case that can be subclassed, he must design the class so it
can be done. I was merely suggesting a way to do that.
Conclusion:
- adding the constructor with a pointer on the fixture add a lot of
flexibility to test caller.
- enforcing the use of the constructor by reference remove a lot of
flexility.
To do cppunit:
- remove TestRegistry.cpp/.h
- implement a TextTestRunner
To do for the sample:
- add a suite() method for each test case, which returns a
dynamically allocated suite,
- add the suite of each test case to the TextTestRunner,
- run the TextTestRunner.
=> this would make it similar to run suite using a graphic or text
TestRunner, and would show how test case should be factored.
> Please try it again. Also check if you can get shell access with SSH on
cppunit.sourceforge.net.
OK, I'll try that.
|
|
From: Bastiaan B. <bas...@li...> - 2001-05-08 22:33:40
|
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.
> They don't have a test caller class because the test caller is the test
> case itself. Here is a piece of code extracted from
> TestSuite.addTestMethod() (called for each public test method on
> construction):
>
> if (isPublicTestMethod(m)) {
> names.addElement(name);
>
> Object[] args= new Object[]{name};
> try {
> addTest((Test)constructor.newInstance(args)); // <=== a new
> instance is created which take the name of the method in the constructor !
> } catch (Exception t) {
> addTest(warning("Cannot instantiate test case: "+name));
> }
>
> and in TestCase.runTest() that do what our test caller is doing:
> // fname is the name specified on construction of the test case, the name of
> the method to run!
> runMethod= getClass().getMethod(fName, new Class[0]);
> [...]
> try {
> runMethod.invoke(this, new Class[0]);
> }
>
> This exactly what our test caller do... In some way we have even more
> flexibility because we can decorate the test caller (adding running time
> constraint, expecting some exception...).
>
Hmm, yes, didn't look beyond the reflection stuff in TestCase. Don't know why
the Java version needs separate TestCase instances per Test though. Maybe
concurrency safety, since Java doesn't have the 'object ownership' problem at
least.
--8<--
>
>
> > 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?
> Its depends how you make your code. I use IDE macro to generate and adds
> file to the project. I just check a box to say "this class is a cppunit
> test case", and it adds everything I need to make the class a test case
> (static suite method, inheritance, includes...). This way I remove all the
> problem you have when using cut and paste to do that.
>
> > Ahem, the amended 'hierarchy' example seems like a perfectly valid example
> of how to use the same fixture for multiple TestCallers. Any objections?
>
> There is a very bad thing about the way its done: you enforce the class
> owning the test caller to also own a reference to the test case. Any class
> you give the test caller to, must also own the instance of the test case
> that was used to create the test caller.
I don't see that. You only have to ensure the TestCase lives longer than the
TestCallers, right?
>
> To me this is a big loss of flexibility. It makes it harder to use stuff
> such as decorator and break the "ownership" policy that is everywhere in the
> framework:
> TestSuite owns all its tests (sub-suite, TestCaller, ...)
> TestCaller owns all its TestCase
> TestCase owns resources needed to run the test.
> Each component of the hierarchy can be taken out of the system and works
> on its one. The TestCaller does not need the TestSuite to be able to run.
>
> Usually, you don't build test case on the stack. You have a static
> suite() method in the test case returning a new TestSuite object. With the
> new ownership policy, you would have to subclass TestSuite so it could hold
> (and own) a reference on the TestCase instance.
>
> To sum it up:
> - the TestCaller would not be able to be a component running on its one
> (you could not pass it to the TestRunner because it need something "above"
> owning the test case).
> - you provided a valid example of use of the test caller with a
> reference on the test case. Though there are underlying constraints to that
> use case (at suite level).
> - this would break one of the constructor of TestSuiteBuilder since it
> could not use the generic TestSuite class, but would need to instantiate its
> owns subclassed TestSuite.
>
> Sharing the reference on the test case does not make it easier to use,
> and split from the ownership policy that is in the framework. Using the
> standard template factory method pattern (makeFixture()) seems a lot easier
> to me and much more flexible.
>
> >
> > >
> > > 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.
> > > - add 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 :-)
> I was not suggesting adding the makeFixture() method in the library.
> This is a user choice (just like having a registerTests() method). If the
> user make a test case that can be subclassed, he must design the class so it
> can be done. I was merely suggesting a way to do that.
>
> Conclusion:
> - adding the constructor with a pointer on the fixture add a lot of
> flexibility to test caller.
> - enforcing the use of the constructor by reference remove a lot of
> flexility.
>
> To do cppunit:
> - remove TestRegistry.cpp/.h
> - implement a TextTestRunner
>
> To do for the sample:
> - add a suite() method for each test case, which returns a
> dynamically allocated suite,
> - add the suite of each test case to the TextTestRunner,
> - run the TextTestRunner.
> => this would make it similar to run suite using a graphic or text
> TestRunner, and would show how test case should be factored.
>
OK, thanks for the explanation. Unfortunately until the weekend I don't have
the time to sort it out: got an exam this friday. So this would stall the
release of 1.5.5 until at least somewhere next week.
If otherwise the current tree is OK (and it is, isn't it?), I wouldn't want to
deprive people from Win32 support until then, and release 1.5.5 as an ad
interim version. May give us some useful feedback from others too. If there're
are no nay-sayers, I'll put it on source forge tomorrow.
Bastiaan
|
|
From: Baptiste L. <bl...@cl...> - 2001-05-09 19:39:07
|
> OK, thanks for the explanation. Unfortunately until the weekend I don't
have
> the time to sort it out: got an exam this friday. So this would stall the
> release of 1.5.5 until at least somewhere next week.
> If otherwise the current tree is OK (and it is, isn't it?), I wouldn't
want to
> deprive people from Win32 support until then, and release 1.5.5 as an ad
> interim version. May give us some useful feedback from others too. If
there're
> are no nay-sayers, I'll put it on source forge tomorrow.
Go ahead with release 1.5.5, I don't see any reason not to make a new
release.
Baptiste.
---
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).
|
|
From: Townsend, G. <gto...@sh...> - 2001-05-11 21:06:12
|
Just one thing I realized today about the solution below: dynamically allocating the suite in the test case could be dangerous; at least given the current environment on Win32. The issue is that there are multiple DLLs and the application, all of which could be using different versions of the run-time library. It may not be safe to call delete on memory allocated in a different module. While it is in the same process space, the actual code in the RTLs could be different, depending on how each module was linked. (ie. static RTL vs DLL RTL vs multi or single threaded vs different versions of compiler). I recently read about this all too common problem in Jeffrey Richter's "Programming Applications for Microsoft Windows - Fourth Edition" Given his expertise level, I would have to bet it's a real problem that should be avoided. The bottom line is that memory allocated in a given module should be freed in that same module. The basic problem is memory leaks, which is not a _huge_ problem for these applications, since after the test application closes, the OS will clean up any memory allocated in that process. ( at least NT/Win2K will do that properly) On the other hand, creating code that doesn't cause memory leaks is still much preferrable. This may be an issue in other places in the code too, although the main problem area will only be the TestRunner DLL freeing memory allocated elsewhere. On the other hand, if the base TestRunner class does the memory freeing (deletes the suite), and it ends up in the cppunit (statically linked) library, then we're okay. Perhaps this will work out more easily than I first thought... Guy -----Original Message----- From: Townsend, Guy [mailto:gto...@sh...] Sent: Thursday, May 10, 2001 6:24 PM To: 'cpp...@li...' Subject: RE: [Cppunit-devel] hierarchy sample bug... FWIW, I agree with the following solution. >> To do cppunit: >> - remove TestRegistry.cpp/.h >> - implement a TextTestRunner >> >> To do for the sample: >> - add a suite() method for each test case, which returns a >> dynamically allocated suite, >> - add the suite of each test case to the TextTestRunner, >> - run the TextTestRunner. >> => this would make it similar to run suite using a graphic or text >> TestRunner, and would show how test case should be factored. As a cppunit newbie, this would make a lot of sense to me. There are so many options that it's a little overwhelming. I also don't want to restructure all my test code when the next release comes out. The proposed solution would allow both automated text based tests and interactive tests, from essentially the same code. This would be best accomplished if there were slight changes to make TestRunner have a pure virtual run() method and then have a TextTestRunner and a GuiTestRunner. The GuiTestRunners could changed slightly for different platforms. I realize I'm late to the discussion and perhaps I don't understand all the issues. I see that there has so far been no effort to create a GUI TestRunner for other platforms. (although I am extremely grateful that it has been done for Windows, where I'm currently developing!!) Seems like at least the base TestRunner class would end up in cppunit, with only the platform specific parts in directories under src and in parallel with cppunit and msvc6. > OK, thanks for the explanation. Unfortunately until the weekend I don't have the time to sort it out: got an exam this friday. So this would stall the release of 1.5.5 until at least somewhere next week. If otherwise the current tree is OK (and it is, isn't it?), I wouldn't want to deprive people from Win32 support until then, and release 1.5.5 as an ad interim version. May give us some useful feedback from others too. If there're are no nay-sayers, I'll put it on source forge tomorrow. Thanks for getting the Win32 support out! I was doing many of the same fixes to get in synch with the SoureForge version, but at least compile with MSVC. Getting it all merged in was a real bonus! Saved me a lot of time. I'm not sure how much time I can spare, but I am hoping that I can contribute to some degree, including documentation. As usual, the docs are secondary to getting working code (and getting the design bugs worked out). I find myself jumping around a lot of different documents and geting confused about all the new features that aren't really documented. Luckily I can still use the basic classes and get useful work done. I've done a lot of documentation in the past, including full databook writing and editing; and actually don't mind it at all. (however I still have work deadlines to meet first...) It's not clear to me however if it is worth updating the cookbook until the next round of stuff with TestRunner is straightened up... Hope this is not too much in one message, but I also suggest the suite() method be added to either Test or TestCase. I have been seeing a lot of discussion about this method, including in the CppUnit Cookbook document, and it's confusing for it not to be a virtual method in one of the base classes. It would also provide a good place to add some documentation for its use. Guy _______________________________________________ Cppunit-devel mailing list Cpp...@li... http://lists.sourceforge.net/lists/listinfo/cppunit-devel |
|
From: Baptiste L. <bl...@cl...> - 2001-05-12 15:45:41
|
> Just one thing I realized today about the solution below: dynamically
> allocating the suite in the test case could be dangerous; at least given
the
> current environment on Win32. The issue is that there are multiple DLLs
and
> the application, all of which could be using different versions of the
> run-time library. It may not be safe to call delete on memory allocated in
a
> different module. While it is in the same process space, the actual code
in
> the RTLs could be different, depending on how each module was linked. (ie.
> static RTL vs DLL RTL vs multi or single threaded vs different versions of
> compiler). I recently read about this all too common problem in Jeffrey
> Richter's "Programming Applications for Microsoft Windows - Fourth
Edition"
> Given his expertise level, I would have to bet it's a real problem that
> should be avoided. The bottom line is that memory allocated in a given
> module should be freed in that same module.
This is a real problem when you release DLL which you have no control
over, but that is not the case here. Unit test are of use for us,
developers, not for the clients. You only have to know what you are doing
when splitting your code into DLL (and its nigh impossible to successful
compile against a library that is using different RTL setting, you always
ends up with some conflicts at link time).
Also, unit testing is of use for development, but should not be in the
final published interface of the DLL. If you want to mix up RTL setting in
different DLL, you will run into trouble and you would need to use the usual
encapsulation technics to solve them. The same technic can be applied to the
DLL published suite. You could use a encapsulating suite that delegate
instantiation and destruction of the "published" suite to the DLL.
I think that this problem should not be solved by cppunit, as solution
depends much on the use, platform... On the other hand it may be interesting
to document it, and some of the possible solution.
>
> The basic problem is memory leaks, which is not a _huge_ problem for these
> applications, since after the test application closes, the OS will clean
up
> any memory allocated in that process. ( at least NT/Win2K will do that
Memory leaks are very important, and you should always minimize them. If
you don't destroy test, you will make memory leaks detection tools useless.
You application may not be closed for weeks or months (your standard server,
for example). Unit test have this marvelous property that they use the code
in many way. Chasing the memory leak (when they occurs in some weird
context) is usually easy that way.
> properly) On the other hand, creating code that doesn't cause memory leaks
> is still much preferrable. This may be an issue in other places in the
code
> too, although the main problem area will only be the TestRunner DLL
freeing
> memory allocated elsewhere.
>
> On the other hand, if the base TestRunner class does the memory freeing
> (deletes the suite), and it ends up in the cppunit (statically linked)
> library, then we're okay. Perhaps this will work out more easily than I
> first thought...
This wouldn't works. Some suite/test given to the test runner could be
instantiated by the host application. A suite can be instantiated by test
runner (it automatically creates a "all tests" suite if more than one test
was registered). See above for the solution I propose.
|
|
From: Baptiste L. <bl...@cl...> - 2001-05-07 09:57:51
|
> I've implemented the fix I suggested yesterday: TestCaller now has two
extra
> constructors which accept either a reference or a pointer to an existing
> fixture as an extra parameter. Now GameBoardTest constructs a TestCaller
> with *this as Fixture and the correct setUp(), tearDown() and testmethod
are
> called.
> I don't see why every TestCaller needs its own Fixture instance, so if
there
> aren't any objections I'd like to deprecate the old constructor.
> Please let me know if you see any flaws in this approach.
I would let the old constructor alone, but indicates in the
documentation that the new one should be used instead.
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...
>
> Bastiaan
>
>
> Baptiste.
> ---
> 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
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X