From: Barrie T. <bae...@gm...> - 2005-03-18 03:46:45
|
I notice the unit test in junit.tests.framework.TestCaseTest.testTearDownSetupFails() specifically is written to show that an Exception in setUp() does not call tearDown(). Is there a reason for this? I've tried searching on the net for the reason behind it by have come up blank. When I place setup code inside the test and an Exception occurs the tearDown() method will be called. However, if I then move this to be common across all test fixtures by placing it inside setUp() then the test behaves differently because now tearDown() is not called. Can anyone provide any insights into this please? Thanks Bae |
From: Dean H. <de...@xs...> - 2005-03-18 14:49:47
|
may be a bug. I remember some code I submitted a while back to JUnit was committed with a bug, and I sent a message that it needed to be fixed but don't know if it was. Basically, JUnit is now supposed to run setup and if there is an exception save it, run teardown and if there is another exception, discard it and throw the one from setup. Same for test cases. This is because alot of the time, an exception in teardown can be due to an exception in the test case or the setup that happened first and if the first one is fixed, the teardown will be fixed to. thanks, dean ----- Original Message ----- From: "Barrie Treloar" <bae...@gm...> To: <jun...@li...> Sent: Thursday, March 17, 2005 8:46 PM Subject: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()? >I notice the unit test in > junit.tests.framework.TestCaseTest.testTearDownSetupFails() > specifically is written to show that an Exception in setUp() does not > call tearDown(). > > Is there a reason for this? > I've tried searching on the net for the reason behind it by have come up > blank. > > When I place setup code inside the test and an Exception occurs the > tearDown() method will be called. > > However, if I then move this to be common across all test fixtures by > placing it inside setUp() then the test behaves differently because > now tearDown() is not called. > > Can anyone provide any insights into this please? > > Thanks > Bae > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel |
From: Barrie T. <bae...@gm...> - 2005-03-19 06:01:35
|
Do you have code for this, or should I grab the cvs and submit a patch myself? On Fri, 18 Mar 2005 07:53:07 -0700, Dean Hiller <de...@xs...> wrote: > may be a bug. I remember some code I submitted a while back to JUnit was > committed with a bug, and I sent a message that it needed to be fixed but > don't know if it was. > > Basically, JUnit is now supposed to run setup and if there is an exception > save it, run teardown and if there is another exception, discard it and > throw the one from setup. Same for test cases. This is because alot of the > time, an exception in teardown can be due to an exception in the test case > or the setup that happened first and if the first one is fixed, the teardown > will be fixed to. > thanks, > dean > > ----- Original Message ----- > From: "Barrie Treloar" <bae...@gm...> > To: <jun...@li...> > Sent: Thursday, March 17, 2005 8:46 PM > Subject: [Junit-devel] Why is tearDown() not called when there are > exceptions in setUp()? > > >I notice the unit test in > > junit.tests.framework.TestCaseTest.testTearDownSetupFails() > > specifically is written to show that an Exception in setUp() does not > > call tearDown(). > > > > Is there a reason for this? > > I've tried searching on the net for the reason behind it by have come up > > blank. > > > > When I place setup code inside the test and an Exception occurs the > > tearDown() method will be called. > > > > However, if I then move this to be common across all test fixtures by > > placing it inside setUp() then the test behaves differently because > > now tearDown() is not called. > > > > Can anyone provide any insights into this please? > > > > Thanks > > Bae > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Junit-devel mailing list > > Jun...@li... > > https://lists.sourceforge.net/lists/listinfo/junit-devel > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > |
From: Barrie T. <bae...@gm...> - 2005-03-20 08:23:31
|
It was an easy fix. I've submitted patch id 1166866. On Sat, 19 Mar 2005 16:31:28 +1030, Barrie Treloar <bae...@gm...> wrote: > Do you have code for this, or should I grab the cvs and submit a patch myself? > > > On Fri, 18 Mar 2005 07:53:07 -0700, Dean Hiller <de...@xs...> wrote: > > may be a bug. I remember some code I submitted a while back to JUnit was > > committed with a bug, and I sent a message that it needed to be fixed but > > don't know if it was. > > > > Basically, JUnit is now supposed to run setup and if there is an exception > > save it, run teardown and if there is another exception, discard it and > > throw the one from setup. Same for test cases. This is because alot of the > > time, an exception in teardown can be due to an exception in the test case > > or the setup that happened first and if the first one is fixed, the teardown > > will be fixed to. > > thanks, > > dean > > > > ----- Original Message ----- > > From: "Barrie Treloar" <bae...@gm...> > > To: <jun...@li...> > > Sent: Thursday, March 17, 2005 8:46 PM > > Subject: [Junit-devel] Why is tearDown() not called when there are > > exceptions in setUp()? > > > > >I notice the unit test in > > > junit.tests.framework.TestCaseTest.testTearDownSetupFails() > > > specifically is written to show that an Exception in setUp() does not > > > call tearDown(). > > > > > > Is there a reason for this? > > > I've tried searching on the net for the reason behind it by have come up > > > blank. > > > > > > When I place setup code inside the test and an Exception occurs the > > > tearDown() method will be called. > > > > > > However, if I then move this to be common across all test fixtures by > > > placing it inside setUp() then the test behaves differently because > > > now tearDown() is not called. > > > > > > Can anyone provide any insights into this please? > > > > > > Thanks > > > Bae > > > > > > > > > ------------------------------------------------------- > > > SF email is sponsored by - The IT Product Guide > > > Read honest & candid reviews on hundreds of IT Products from real users. > > > Discover which products truly live up to the hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > > Junit-devel mailing list > > > Jun...@li... > > > https://lists.sourceforge.net/lists/listinfo/junit-devel > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Junit-devel mailing list > > Jun...@li... > > https://lists.sourceforge.net/lists/listinfo/junit-devel > > > |
From: Dean H. <de...@xs...> - 2005-03-20 16:11:59
|
yup, finally got to looking at it...just a matter of moving setup method into the try block. cool, should be a bit nicer. dean ----- Original Message ----- From: "Barrie Treloar" <bae...@gm...> To: "Dean Hiller" <de...@xs...> Cc: <jun...@li...> Sent: Sunday, March 20, 2005 1:23 AM Subject: Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()? > It was an easy fix. > I've submitted patch id 1166866. > > > On Sat, 19 Mar 2005 16:31:28 +1030, Barrie Treloar <bae...@gm...> > wrote: >> Do you have code for this, or should I grab the cvs and submit a patch >> myself? >> >> >> On Fri, 18 Mar 2005 07:53:07 -0700, Dean Hiller <de...@xs...> >> wrote: >> > may be a bug. I remember some code I submitted a while back to JUnit >> > was >> > committed with a bug, and I sent a message that it needed to be fixed >> > but >> > don't know if it was. >> > >> > Basically, JUnit is now supposed to run setup and if there is an >> > exception >> > save it, run teardown and if there is another exception, discard it and >> > throw the one from setup. Same for test cases. This is because alot >> > of the >> > time, an exception in teardown can be due to an exception in the test >> > case >> > or the setup that happened first and if the first one is fixed, the >> > teardown >> > will be fixed to. >> > thanks, >> > dean >> > >> > ----- Original Message ----- >> > From: "Barrie Treloar" <bae...@gm...> >> > To: <jun...@li...> >> > Sent: Thursday, March 17, 2005 8:46 PM >> > Subject: [Junit-devel] Why is tearDown() not called when there are >> > exceptions in setUp()? >> > >> > >I notice the unit test in >> > > junit.tests.framework.TestCaseTest.testTearDownSetupFails() >> > > specifically is written to show that an Exception in setUp() does not >> > > call tearDown(). >> > > >> > > Is there a reason for this? >> > > I've tried searching on the net for the reason behind it by have come >> > > up >> > > blank. >> > > >> > > When I place setup code inside the test and an Exception occurs the >> > > tearDown() method will be called. >> > > >> > > However, if I then move this to be common across all test fixtures by >> > > placing it inside setUp() then the test behaves differently because >> > > now tearDown() is not called. >> > > >> > > Can anyone provide any insights into this please? >> > > >> > > Thanks >> > > Bae >> > > >> > > >> > > ------------------------------------------------------- >> > > SF email is sponsored by - The IT Product Guide >> > > Read honest & candid reviews on hundreds of IT Products from real >> > > users. >> > > Discover which products truly live up to the hype. Start reading now. >> > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> > > _______________________________________________ >> > > Junit-devel mailing list >> > > Jun...@li... >> > > https://lists.sourceforge.net/lists/listinfo/junit-devel >> > >> > ------------------------------------------------------- >> > SF email is sponsored by - The IT Product Guide >> > Read honest & candid reviews on hundreds of IT Products from real >> > users. >> > Discover which products truly live up to the hype. Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> > _______________________________________________ >> > Junit-devel mailing list >> > Jun...@li... >> > https://lists.sourceforge.net/lists/listinfo/junit-devel >> > >> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel |
From: Kent B. <ke...@ea...> - 2005-03-23 07:10:08
|
Dean, Thank you for submitting your patch. The current behavior is deliberate. My reasoning for the current behavior is that if setUp() fail, then tearDown() is useless. SetUp() should never fail. If it does, the whole premise of the test is false. Do you have concrete examples where tearDown() would be useful even if setUp() fail? Kent Beck Three Rivers Institute > -----Original Message----- > From: jun...@li... > [mailto:jun...@li...] On Behalf Of > Dean Hiller > Sent: Friday, March 18, 2005 6:53 AM > To: Barrie Treloar; jun...@li... > Subject: Re: [Junit-devel] Why is tearDown() not called when > there are exceptions in setUp()? > > > may be a bug. I remember some code I submitted a while back > to JUnit was > committed with a bug, and I sent a message that it needed to > be fixed but > don't know if it was. > > Basically, JUnit is now supposed to run setup and if there is > an exception > save it, run teardown and if there is another exception, > discard it and > throw the one from setup. Same for test cases. This is > because alot of the > time, an exception in teardown can be due to an exception in > the test case > or the setup that happened first and if the first one is > fixed, the teardown > will be fixed to. > thanks, > dean > > ----- Original Message ----- > From: "Barrie Treloar" <bae...@gm...> > To: <jun...@li...> > Sent: Thursday, March 17, 2005 8:46 PM > Subject: [Junit-devel] Why is tearDown() not called when there are > exceptions in setUp()? > > > >I notice the unit test in > > junit.tests.framework.TestCaseTest.testTearDownSetupFails() > > specifically is written to show that an Exception in > setUp() does not > > call tearDown(). > > > > Is there a reason for this? > > I've tried searching on the net for the reason behind it by > have come up > > blank. > > > > When I place setup code inside the test and an Exception occurs the > > tearDown() method will be called. > > > > However, if I then move this to be common across all test > fixtures by > > placing it inside setUp() then the test behaves differently because > > now tearDown() is not called. > > > > Can anyone provide any insights into this please? > > > > Thanks > > Bae > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products > from real users. > > Discover which products truly live up to the hype. Start > reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Junit-devel mailing list > > Jun...@li... > > https://lists.sourceforge.net/lists/listinfo/junit-devel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > |
From: Barrie T. <bae...@gm...> - 2005-03-23 22:16:26
|
Maybe we are using JUnit wrong, but here is our scenario. We want to ensure that our data access objects correctly mirror the database. By writing unit tests we ensure that any changes to the database that break our DAOs get reported quickly. Prior to building these unit tests we didn't know anything was broken for up to two days, now we know within 30 minutes of the database being changed whether our build is broken. So we could write tests like: test 1 - setup for test 1 - connect to database - insert into database - DO TEST - teardown for test 1 - delete anything inserted for test test 2 - setup for test 2 - connect to database - insert into database - DO TEST - teardown for test 2 - delete anything inserted for test Here each test has complete control over its local setUp and tearDown and we can write the code so that the local tearDown is always called. However, the local setUps and tearDowns have duplicate code so we pushed it into the test's setUp and tearDown methods. I can see your reasoning behind the current implementation and re-reading the javadoc I can see that tearDown is invoked "...after a test is executed.". With the current version though I can't push my duplicate code in local setUp/tearDown into the test's setUp/tearDown as tearDown isn't called if setUp failed. Since you can't guarantee how much of setUp was successful when setUp fails it's tearDowns job to ensure that as it cleans up that nothing is assumed about the state from setUp. In our scenario setUp inserts some data and then fails to insert other data because the database has changed. With the current version tearDown doesn't get invoked when setUp failed so our database is left in an inconsistent state. I hope I have articulated the need correctly here. In summary: Without the patch each test needs to invoke a tearDown like method to cleanup. A bit ugly but doable. With the patch tearDown is always invoked, even if setUp fails, and tearDown can be written to handle partial success of setUp. Bae On Tue, 22 Mar 2005 23:05:15 -0800, Kent Beck <ke...@ea...> wrote: > Dean, > > Thank you for submitting your patch. The current behavior is deliberate. My > reasoning for the current behavior is that if setUp() fail, then tearDown() > is useless. SetUp() should never fail. If it does, the whole premise of the > test is false. Do you have concrete examples where tearDown() would be > useful even if setUp() fail? > > Kent Beck > Three Rivers Institute > > > -----Original Message----- > > From: jun...@li... > > [mailto:jun...@li...] On Behalf Of > > Dean Hiller > > Sent: Friday, March 18, 2005 6:53 AM > > To: Barrie Treloar; jun...@li... > > Subject: Re: [Junit-devel] Why is tearDown() not called when > > there are exceptions in setUp()? > > > > > > may be a bug. I remember some code I submitted a while back > > to JUnit was > > committed with a bug, and I sent a message that it needed to > > be fixed but > > don't know if it was. > > > > Basically, JUnit is now supposed to run setup and if there is > > an exception > > save it, run teardown and if there is another exception, > > discard it and > > throw the one from setup. Same for test cases. This is > > because alot of the > > time, an exception in teardown can be due to an exception in > > the test case > > or the setup that happened first and if the first one is > > fixed, the teardown > > will be fixed to. > > thanks, > > dean > > > > ----- Original Message ----- > > From: "Barrie Treloar" <bae...@gm...> > > To: <jun...@li...> > > Sent: Thursday, March 17, 2005 8:46 PM > > Subject: [Junit-devel] Why is tearDown() not called when there are > > exceptions in setUp()? > > > > > > >I notice the unit test in > > > junit.tests.framework.TestCaseTest.testTearDownSetupFails() > > > specifically is written to show that an Exception in > > setUp() does not > > > call tearDown(). > > > > > > Is there a reason for this? > > > I've tried searching on the net for the reason behind it by > > have come up > > > blank. > > > > > > When I place setup code inside the test and an Exception occurs the > > > tearDown() method will be called. > > > > > > However, if I then move this to be common across all test > > fixtures by > > > placing it inside setUp() then the test behaves differently because > > > now tearDown() is not called. > > > > > > Can anyone provide any insights into this please? > > > > > > Thanks > > > Bae > > > > > > > > > ------------------------------------------------------- > > > SF email is sponsored by - The IT Product Guide > > > Read honest & candid reviews on hundreds of IT Products > > from real users. > > > Discover which products truly live up to the hype. Start > > reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > > Junit-devel mailing list > > > Jun...@li... > > > https://lists.sourceforge.net/lists/listinfo/junit-devel > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from > > real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Junit-devel mailing list > > Jun...@li... > > https://lists.sourceforge.net/lists/listinfo/junit-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register > by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > |
From: Curt S. <cj...@cy...> - 2005-06-07 14:08:35
|
On Thu, 24 Mar 2005, Barrie Treloar wrote: > In our scenario setUp inserts some data and then fails to insert other > data because the database has changed. With the current version > tearDown doesn't get invoked when setUp failed so our database is left > in an inconsistent state. BTW, the most reliable way I've found to deal with this sort of problem is to start a transaction (turn off auto-commit) at the beginning of every unit test and then do a rollback in the teardown. Even if you don't execute the teardown the transaction should be rolled back when the connection goes back into the pool or is closed. This sometimes takes a bit of work to get the DB set up such that unit tests don't need to cross transaction boundaries, but I've found it quite worthwhile because you have a much better guarantee that each test is starting from a consistent state: it's impossible to forget to undo DB changes. cjs -- Curt Sampson <cj...@cy...> +81 90 7737 2974 http://www.NetBSD.org Make up enjoying your city life...produced by BIC CAMERA |
From: Dean H. <de...@xs...> - 2005-03-24 04:50:33
|
I need to read my mail backwards. Interesting. Yes, this is just like static variables too. The interesting thing though is you have the option here to clearDB in setup, and then setup what you need so any previous test does not affect the next test. In fact, can't you move the code in tearDown to the top of the setup method. Also, isn't there a mock project that helps more with this too(is it mockrunner?) dean ----- Original Message ----- From: "Barrie Treloar" <bae...@gm...> To: "Kent Beck" <ke...@ea...> Cc: "Dean Hiller" <de...@xs...>; <jun...@li...> Sent: Wednesday, March 23, 2005 3:16 PM Subject: Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()? > Maybe we are using JUnit wrong, but here is our scenario. > > We want to ensure that our data access objects correctly mirror the > database. > By writing unit tests we ensure that any changes to the database that > break our DAOs get reported quickly. Prior to building these unit > tests we didn't know anything was broken for up to two days, now we > know within 30 minutes of the database being changed whether our build > is broken. > > So we could write tests like: > > test 1 > - setup for test 1 > - connect to database > - insert into database > - DO TEST > - teardown for test 1 > - delete anything inserted for test > > test 2 > - setup for test 2 > - connect to database > - insert into database > - DO TEST > - teardown for test 2 > - delete anything inserted for test > > Here each test has complete control over its local setUp and tearDown > and we can write the code so that the local tearDown is always called. > > However, the local setUps and tearDowns have duplicate code so we > pushed it into the test's setUp and tearDown methods. I can see your > reasoning behind the current implementation and re-reading the javadoc > I can see that tearDown is invoked "...after a test is executed.". > With the current version though I can't push my duplicate code in > local setUp/tearDown into the test's setUp/tearDown as tearDown isn't > called if setUp failed. > > Since you can't guarantee how much of setUp was successful when setUp > fails it's tearDowns job to ensure that as it cleans up that nothing > is assumed about the state from setUp. > > In our scenario setUp inserts some data and then fails to insert other > data because the database has changed. With the current version > tearDown doesn't get invoked when setUp failed so our database is left > in an inconsistent state. > > I hope I have articulated the need correctly here. > > In summary: > Without the patch each test needs to invoke a tearDown like method to > cleanup. A bit ugly but doable. > > With the patch tearDown is always invoked, even if setUp fails, and > tearDown can be written to handle partial success of setUp. > > Bae > > On Tue, 22 Mar 2005 23:05:15 -0800, Kent Beck <ke...@ea...> wrote: >> Dean, >> >> Thank you for submitting your patch. The current behavior is deliberate. >> My >> reasoning for the current behavior is that if setUp() fail, then >> tearDown() >> is useless. SetUp() should never fail. If it does, the whole premise of >> the >> test is false. Do you have concrete examples where tearDown() would be >> useful even if setUp() fail? >> >> Kent Beck >> Three Rivers Institute >> >> > -----Original Message----- >> > From: jun...@li... >> > [mailto:jun...@li...] On Behalf Of >> > Dean Hiller >> > Sent: Friday, March 18, 2005 6:53 AM >> > To: Barrie Treloar; jun...@li... >> > Subject: Re: [Junit-devel] Why is tearDown() not called when >> > there are exceptions in setUp()? >> > >> > >> > may be a bug. I remember some code I submitted a while back >> > to JUnit was >> > committed with a bug, and I sent a message that it needed to >> > be fixed but >> > don't know if it was. >> > >> > Basically, JUnit is now supposed to run setup and if there is >> > an exception >> > save it, run teardown and if there is another exception, >> > discard it and >> > throw the one from setup. Same for test cases. This is >> > because alot of the >> > time, an exception in teardown can be due to an exception in >> > the test case >> > or the setup that happened first and if the first one is >> > fixed, the teardown >> > will be fixed to. >> > thanks, >> > dean >> > >> > ----- Original Message ----- >> > From: "Barrie Treloar" <bae...@gm...> >> > To: <jun...@li...> >> > Sent: Thursday, March 17, 2005 8:46 PM >> > Subject: [Junit-devel] Why is tearDown() not called when there are >> > exceptions in setUp()? >> > >> > >> > >I notice the unit test in >> > > junit.tests.framework.TestCaseTest.testTearDownSetupFails() >> > > specifically is written to show that an Exception in >> > setUp() does not >> > > call tearDown(). >> > > >> > > Is there a reason for this? >> > > I've tried searching on the net for the reason behind it by >> > have come up >> > > blank. >> > > >> > > When I place setup code inside the test and an Exception occurs the >> > > tearDown() method will be called. >> > > >> > > However, if I then move this to be common across all test >> > fixtures by >> > > placing it inside setUp() then the test behaves differently because >> > > now tearDown() is not called. >> > > >> > > Can anyone provide any insights into this please? >> > > >> > > Thanks >> > > Bae >> > > >> > > >> > > ------------------------------------------------------- >> > > SF email is sponsored by - The IT Product Guide >> > > Read honest & candid reviews on hundreds of IT Products >> > from real users. >> > > Discover which products truly live up to the hype. Start >> > reading now. >> > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> > > _______________________________________________ >> > > Junit-devel mailing list >> > > Jun...@li... >> > > https://lists.sourceforge.net/lists/listinfo/junit-devel >> > >> > >> > >> > ------------------------------------------------------- >> > SF email is sponsored by - The IT Product Guide >> > Read honest & candid reviews on hundreds of IT Products from >> > real users. >> > Discover which products truly live up to the hype. Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> > _______________________________________________ >> > Junit-devel mailing list >> > Jun...@li... >> > https://lists.sourceforge.net/lists/listinfo/junit-devel >> > >> >> ------------------------------------------------------- >> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 >> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows >> Embedded(r) & Windows Mobile(tm) platforms, applications & content. >> Register >> by 3/29 & save $300 >> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click >> _______________________________________________ >> Junit-devel mailing list >> Jun...@li... >> https://lists.sourceforge.net/lists/listinfo/junit-devel >> |
From: Barrie T. <bae...@gm...> - 2005-03-24 05:25:49
|
Plus: > hmmmm...thanks for making me think about this. I agree. The only problem I > see is when people use statics and have two test classes > AdvancedTest1 > AdvancedTest2 > static state must be reset in teardown if setup affected it. I personally > always stay away from statics and only use static final. Would you be able to explain the problem you see here? I am unable to see any reason why running tearDown() if setUp() fails is any different in this scenario? For example, Currently, setUp fails and tearDown not called - in some method other than tearDown the data needs to be cleaned up. As patched, setUp fails and tearDown is called - the data gets cleaned up. On Wed, 23 Mar 2005 21:50:36 -0700, Dean Hiller <de...@xs...> wrote: > I need to read my mail backwards. Interesting. Yes, this is just like > static variables too. The interesting thing though is you have the option > here to clearDB in setup, and then setup what you need so any previous test > does not affect the next test. In fact, can't you move the code in tearDown > to the top of the setup method. Also, isn't there a mock project that helps > more with this too(is it mockrunner?) > dean We allocate new id's for each object so that two people running the same tests do not get unique id constraints if they are running the tests at the same time. So we can't cleanup in the database changes from the previous test in the setUp() of the next test as you don't know what values where added to the database on the previous test. JUnit rightly starts with a fresh object each time and hence the member variables that would have held this information are not available. Since tests should be independent it doesn't really make sense to have a test's setUp cleanup from a prior tests execution. |