junit-devel — junit developers

[Junit-devel] Junit problem in Eclipse 3.0.1 using jdk1.5.2

[Bill M. <bmc...@sm...>]

I am having a problem running Junit in Eclipse 3.0.1 on a windows XP 
service pack 2 in a new project that I created and I checked out the 
WebApps from CVS into Tomcat557/webapps dir using the new jdk1.5.2 
version.  I have another project setup in Eclipse where it uses the 
jdk1.4.2 in Tomcat50/webapps dir... that one works, but I need to now 
use the new project pointing at the new jdk1.5.2...  I have all the jars 
added to the Library path... the junit3.8.1.jar and all the other jars.  
Output path points to the Tomcat557/webapps/WebApps/WEB-INF/classes 
dir.  I've updated my Path and  JAVA_HOME to point at the new 
C:\jdk1.5.2 and the CATALINA_HOME points at the new C:\Tomcat557...

When I run as Junit Test ... It says: *Test type does not exist....*

Any help would be great thanks!


Bill

Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Barrie T. <bae...@gm...>]

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.

Re: [Junit-devel] An idea to run individual tests as "unimplemented"

[Dean H. <de...@xs...>]

I am utterly confused.  Are you proposing a new category where the 
categories would be
1. passed
2. failed
3. error
4. unexpected pass

Where your proposal is to add #4.
dean


----- Original Message ----- 
From: "Marc Guillemot" <mgu...@ya...>
To: <jun...@li...>
Sent: Tuesday, March 22, 2005 7:31 AM
Subject: [Junit-devel] An idea to run individual tests as "unimplemented"


> Hi,
>
> I'm experimenting a construct that could be interesting for other persons 
> or perhaps in junit itself. Having a test testFutureFunctionality that 
> fails as it tests something that is known as not yet supported, we can 
> remove the test from the normal test run to avoid making the whole run 
> fail or enhance the test with something like:
>
> public void testFutureFunctionality()
> {
>   if (runAsUnimplemented())
>   {
>     return;
>   }
>
>   .... the real test
>
> }
>
> where runAsUnimplemented():
> - puts a flag in the thread to mark that it is called
> - looks in the stack to find the unit test from which it is called,
> - calls this test again (runAsUnimplemented() returning in this case false 
> to have the real test running) catching possible exceptions
> - if the real test is successful, throws an exception reporting that a 
> test marked as unimplemented already works
> - else just return true, to avoid that the real test gets executed and 
> that it throws an exception
>
> This allows tests for future functionality to be incorporated in the rest 
> of the unit tests at their "logical" place, to be run and to fail if the 
> tests are ... successful. This way "good" side effects are detected.
>
> The code necessary to "run as unimplemented" could be improved with an 
> integration in junit and we could imagine that a javadoc tag like 
> @notImplemented would be enough when using java 1.5 annotations.
>
>
> Origin of the idea:
>
> in one open source project on which I work, we try to simulate the 
> behavior of browsers (http://htmlunit.sourceforge.net) and have many junit 
> tests. We don't currently do everything like browser do but have already 
> some tests for functionalities that we should support but that don't 
> currently work. Because the project is already stable, we don't run these 
> tests in our "normal" test run and use a construct like following to skip 
> them:
>
> public void testFutureFunctionality()
> {
>   if (true)
>   {
>     log("Functionality not implemented, skipping test");
>     return;
>   }
>
>   .... the real test
> }
>
> Using these construction, the test are located at their normal place but 
> only there "for documentation" and are never run until a developer removes 
> the lines skipping the execution of the test. With a construct like the 
> one proposed before we can run the test "normally" and detect when a 
> change has an unexpected good side effect.
>
>
> If only one person has been interested and has read this message until the 
> end, then I have perhaps not wasted my time ;-)
>
> Marc.
>
>
>
> -------------------------------------------------------
> 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 

Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Dean H. <de...@xs...>]

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
>> 

Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Dean H. <de...@xs...>]

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.
dean

----- Original Message ----- 
From: "Kent Beck" <ke...@ea...>
To: "'Dean Hiller'" <de...@xs...>; 
<jun...@li...>
Sent: Wednesday, March 23, 2005 12:05 AM
Subject: RE: [Junit-devel] Why is tearDown() not called when there are 
exceptions in setUp()?


> 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
>>
> 

Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Barrie T. <bae...@gm...>]

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
>

RE: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Kent B. <ke...@ea...>]

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
> 

[Junit-devel] An idea to run individual tests as "unimplemented"

[Marc G. <mgu...@ya...>]

Hi,

I'm experimenting a construct that could be interesting for other persons or perhaps in junit itself. Having a test 
testFutureFunctionality that fails as it tests something that is known as not yet supported, we can remove the test from 
the normal test run to avoid making the whole run fail or enhance the test with something like:

public void testFutureFunctionality()
{
   if (runAsUnimplemented())
   {
     return;
   }

   .... the real test

}

where runAsUnimplemented():
- puts a flag in the thread to mark that it is called
- looks in the stack to find the unit test from which it is called,
- calls this test again (runAsUnimplemented() returning in this case false to have the real test running) catching 
possible exceptions
- if the real test is successful, throws an exception reporting that a test marked as unimplemented already works
- else just return true, to avoid that the real test gets executed and that it throws an exception

This allows tests for future functionality to be incorporated in the rest of the unit tests at their "logical" place, to 
be run and to fail if the tests are ... successful. This way "good" side effects are detected.

The code necessary to "run as unimplemented" could be improved with an integration in junit and we could imagine that a 
javadoc tag like @notImplemented would be enough when using java 1.5 annotations.


Origin of the idea:

in one open source project on which I work, we try to simulate the behavior of browsers 
(http://htmlunit.sourceforge.net) and have many junit tests. We don't currently do everything like browser do but have 
already some tests for functionalities that we should support but that don't currently work. Because the project is 
already stable, we don't run these tests in our "normal" test run and use a construct like following to skip them:

public void testFutureFunctionality()
{
   if (true)
   {
     log("Functionality not implemented, skipping test");
     return;
   }

   .... the real test
}

Using these construction, the test are located at their normal place but only there "for documentation" and are never 
run until a developer removes the lines skipping the execution of the test. With a construct like the one proposed 
before we can run the test "normally" and detect when a change has an unexpected good side effect.


If only one person has been interested and has read this message until the end, then I have perhaps not wasted my time ;-)

Marc.

Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Dean H. <de...@xs...>]

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 

Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Barrie T. <bae...@gm...>]

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
> >
>

[Junit-devel] Gary Denner/Ireland/IBM is out of the office.

[Gary D. <Gar...@ie...>]

I will be out of the office starting  18/03/2005 and will not return until
29/03/2005.

I will respond to your message apon my return.

Thanks
Gary

Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Barrie T. <bae...@gm...>]

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
>

Re: [Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Dean H. <de...@xs...>]

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 

Re: [Junit-devel] Writing an adapter from another test framework to junit

[Markus K. <mar...@gm...>]

Thanks Dean
for trying to answer my question. 
Fortunately I got the answer by myself tonight. 

The trick is to use an anonymous class and implement runTest:
 
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;


public class MySuite {

	public static void main(String[] args) {
		
	}
	public static Test suite() {
		 TestCase myTestCase = new TestCase("one") {
			
			
		
			protected void runTest() throws Throwable {
				System.out.println("one");
			}

			
		};
	
		TestSuite suite = new TestSuite("Testsuite");
		
		suite.addTest(myTestCase);
		
		return suite;
	}
}


This way I can instantiate as many TestCases I want and let them call
into our Testframework.


Regards,
Markus


On Thu, 17 Mar 2005 20:11:52 -0700, Dean Hiller <de...@xs...> wrote:
> while Proxy in jdk doesn't work, bcel at apache might work as you should be
> able to dynamically subclass though it might be more than you bargained for.
> 
> I remember once wrapping xml scripts that ran in an ant like framework once
> in JUnit.  I did this all with out any Proxy or dynamic classes from the
> bcel.  ie.  I am not sure why you need it to be so dynamic since JUnit has
> TestSuites and you can write one JUnit TestCase that really represents one
> test in your framework.  I guess I just don't fully understand your
> situation.
> 
> hope some of that helps.
> dean
> 
> ----- Original Message -----
> From: "Markus Kohler" <mar...@gm...>
> To: <Jun...@li...>
> Sent: Thursday, March 17, 2005 12:24 PM
> Subject: [Junit-devel] Writing an adapter from another test framework to
> junit
> 
> > Hi all,
> >
> > I'm asking this question on the devel list, because I think it's a
> > question that goes quite deeply into the design of junit.
> >
> > We have here an internally developed test framework that is used for
> > some of our tests.
> >
> > I'm currently investigating whether it's feasible to  write an adapter
> > that takes a test suite of our internal framework and adapts it to be
> > usable with Junit. Unfortunately this seems to turn out to be
> > impossible without code generation, or byte code modification.
> >
> > As far as I can see there's no other way to create tests than
> > subclassing TestCase. Since TestCase  is not an interface, but an
> > abstract class, using a dynamic proxy is impossible.
> >
> > Any help would be appreciated.
> >
> >
> >
> > Regards,
> > Markus
> >
> >
> > -------------------------------------------------------
> > 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
> 
>

[Junit-devel] Why is tearDown() not called when there are exceptions in setUp()?

[Barrie T. <bae...@gm...>]

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

[Junit-devel] Writing an adapter from another test framework to junit

[Markus K. <mar...@gm...>]

Hi all, 

I'm asking this question on the devel list, because I think it's a
question that goes quite deeply into the design of junit.

We have here an internally developed test framework that is used for
some of our tests.

I'm currently investigating whether it's feasible to  write an adapter
that takes a test suite of our internal framework and adapts it to be
usable with Junit. Unfortunately this seems to turn out to be 
impossible without code generation, or byte code modification.

As far as I can see there's no other way to create tests than
subclassing TestCase. Since TestCase  is not an interface, but an
abstract class, using a dynamic proxy is impossible.

Any help would be appreciated. 



Regards,
Markus

[Junit-devel] parked?

[Vic C. <cek...@gm...>]

Is this a parked project?
New releases coming?
JMock, Swing testing and scenarios? 

.V

Re: [Junit-devel] Fwd: TestCaseClassLoader (HELP)

[Harring F. <har...@ya...>]

 I  found out the problem.

 Chuck McManis wrote this life-saver article explaining the reason. Indeed a
must read to any java programmer.
 THANKS CHUCK (if you happen to find this email :P) !!

Harring.

http://www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth-p2.html


--- Harring Figueiredo <har...@ya...> wrote:

> 
>  Folks: I posted this on the developer's list and got no reply.
> 
>  Hope this is the right list. Thank you for any help.
> 
> 
>  
>   I am trying to use the TestCaseClassLoader to load some of my classes (For
> a
>  different project :P).
>  
>   I got it to work with a rather strange behavior. I am sure it is more of a 
>   'id 10 t' type of error :).
>  
>   Here is what I have:
>  
>    C implements CI   
>  
>  
>   I can load C correctly; however, it says that C is not an intance of CI.
>  
>   If I use the default class loader, it indeed says it is an 'instanceof' CI.
>  
>   Andy ideas ?  
>  
>   Thanks for any help in advance!
>  
>  (Here is the code.) 
>  
>   /**** C class  no package define -- I don't think it matters...*/  
>   import somepackage;
>   public class C implements CI{
>       public C() { System.out.println("Hello World"); }
>       public void sayHello(){ System.out.println("Say Hello");
>   }
>   
>   /** CI interface **/
>   package somepacckage;
>   public interface CI{
>      public void sayHello();
>   }
>  
>   class Test {
>   public static void main(String[] args)
>   {
>      try{
>        TestCaseClassLoader cl= new
>        TestCaseClassLoader(/* Classpath is defined !!! */);
>  
>        Class c = cl.loadClass("C", true);
>        //Class c = cl.getClass().forName("C"); <== THIS WORKS !!!
>        Object o = c.newInstance();
>        System.out.println(o.getClass().getName()); // Prints C
>         
>        System.out.println(" Object "+
>  o.getClass().getClassLoader().toString()); // Returns TestClassLoader
> 
>        if( o instanceof CI){ // goes here with default system classloader
>             System.out.println(" Instance "+ o.getClass().getName());
>              ci = (CI)o;
>        }
>        else{   // GOES here with the TestClassLoader
>                 System.out.println("NOT Instance "+
>                 o.getClass().getName());
>        }
>  }
>    
>  
>  
>  		
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> -------------------------------------------------------
> 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
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

[Junit-devel] Fwd: TestCaseClassLoader (HELP)

[Harring F. <har...@ya...>]

 Folks: I posted this on the developer's list and got no reply.

 Hope this is the right list. Thank you for any help.


 
  I am trying to use the TestCaseClassLoader to load some of my classes (For a
 different project :P).
 
  I got it to work with a rather strange behavior. I am sure it is more of a 
  'id 10 t' type of error :).
 
  Here is what I have:
 
   C implements CI   
 
 
  I can load C correctly; however, it says that C is not an intance of CI.
 
  If I use the default class loader, it indeed says it is an 'instanceof' CI.
 
  Andy ideas ?  
 
  Thanks for any help in advance!
 
 (Here is the code.) 
 
  /**** C class  no package define -- I don't think it matters...*/  
  import somepackage;
  public class C implements CI{
      public C() { System.out.println("Hello World"); }
      public void sayHello(){ System.out.println("Say Hello");
  }
  
  /** CI interface **/
  package somepacckage;
  public interface CI{
     public void sayHello();
  }
 
  class Test {
  public static void main(String[] args)
  {
     try{
       TestCaseClassLoader cl= new
       TestCaseClassLoader(/* Classpath is defined !!! */);
 
       Class c = cl.loadClass("C", true);
       //Class c = cl.getClass().forName("C"); <== THIS WORKS !!!
       Object o = c.newInstance();
       System.out.println(o.getClass().getName()); // Prints C
        
       System.out.println(" Object "+
 o.getClass().getClassLoader().toString()); // Returns TestClassLoader

       if( o instanceof CI){ // goes here with default system classloader
            System.out.println(" Instance "+ o.getClass().getName());
             ci = (CI)o;
       }
       else{   // GOES here with the TestClassLoader
                System.out.println("NOT Instance "+
                o.getClass().getName());
       }
 }
   
 
 
 		


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Junit-devel] Re:Not Implemented convenience method

[Lars W. <las...@sp...>]

Hi,

I'm only a junior programmer, but since no one has said anything about this 
suggestion yet, I'll chip in my 0.5 Euro.

The TestSuite class throws an error if the test class supplied does not 
contain any test methods at all. The most consistent thing, I would argue, 
would be for the framework to automatically throw an error if a test method 
is empty. However, as far as I can tell javas introspection API can only tell 
us what parameters and return types a method has, not what code is inside it, 
so this is not possible.

Adding new special Exceptions or methods to help people remember to fail any 
un-implemented test methods could be helpful for some users, but on the other 
hand there are many best practices, and each added class or method increases 
complexity (ie size, time to learn for beginners, and possibility for bugs to 
creep in).

Therefore, my opinion is that it is probably best not to add this as a new 
method or class. Perhaps it could be added as a suggestion in the javadoc 
instead.

I think it is a good idea to add as a suggestion for IDE developers though. 
Eclipse for instance when it auto-generates a test class just adds a comment:
//TODO implement this test
inside all generated test methods. Running this test suite shows that all 
tests succeed of course, and it is easy to just go on and forget about it. 
Following the best practices, perhaps they could change it to add this to 
every generated test method
fail("Test not yet implemented") //TODO implement this test.

I'll see if I can suggest this to Eclipse, Netbeans et al.

Cheers,
Lars

[Junit-devel] Not Implemented convenience method

[Paul S. <tk...@tk...>]

According to "Junit in Action" p46:  

Use a "best practice" by throwing an exception for test code that has
not yet been implemented.


So I was thinking, what about adding a convenience method to highlight
this approach.  How does adding a notImplemented() method in Assert
sound?  I'll submit a patch if the idea sounds useful.

In that book, the example implementation of this best practice is:

  throw new RuntimeException("implement me");


Collections uses UnsupportedOperationException for unimplemented
functions.

Of course, perhaps adding a Junit specific Exception also makes sense.
So I could create TestCaseNotImplementedException and have the function
call that.

So what option should be taken?

Option 1: Do nothing, the idea is not useful enough

Option 2: Add function notImplemented to Assert with the following
implementation:
  Option 2a: throw RuntimeException
  Option 2b: throw UnsupportedOperationException
  Option 2c: create new Exception type and throw it (like
TestCaseNotImplementedException)

Option 3: Some other solution or permutation not yet mentioned.


Adding something like this to the framework would bring consistency as
well as highlight this practice and make it convenient.


Paul Sundling
 

[Junit-devel] Not Implemented convenience method

[Paul S. <tk...@tk...>]

According to "Junit in Action" p46:  

Use a "best practice" by throwing an exception for test code that has
not yet been implemented.


So I was thinking, what about adding a convenience method to highlight
this approach.  How does adding a notImplemented() method in Assert
sound?  I'll submit a patch if the idea sounds useful.

In that book, the example implementation of this best practice is:

  throw new RuntimeException("implement me");


Collections uses UnsupportedOperationException for unimplemented
functions.

Of course, perhaps adding a Junit specific Exception also makes sense.
So I could create TestCaseNotImplementedException and have the function
call that.

So what option should be taken?

Option 1: Do nothing, the idea is not useful enough

Option 2: Add function notImplemented to Assert with the following
implementation:
  Option 2a: throw RuntimeException
  Option 2b: throw UnsupportedOperationException
  Option 2c: create new Exception type and throw it (like
TestCaseNotImplementedException)

Option 3: Some other solution or permutation not yet mentioned.


Adding something like this to the framework would bring consistency as
well as highlight this practice and make it convenient.


Paul Sundling
 

[Junit-devel] Suggested javadoc additions

[Lars W. <las...@sp...>]

Hi,

I have included a few suggested additions to javadoc. My first proposed 
changes are the package.html files.

I apologize for sending several HTML attatchments. Unfortunately I was unable 
to create a diff patch from CVS using anonymous access and new files which 
did not exist in the CVS repository. Instead I renamed the files and included 
them here. I would have zipped them, but the Sourceforge mailinglist rejects 
zip files if I understand it correctly.

For instance, the file
junit.awtui.package.html

should be renamed and placed in
junit/awtui/package.html

and so on.


Thanks,
Lars Westergren

[Junit-devel] Suggested patch to README.html

[Lars W. <las...@sp...>]

Hi,

The README.html file included in the JUnit source directory shows at least 56 
errors according to the W3C validator (http://validator.w3.org/). It might 
show correct in most browsers, but I have worked at a library for the blind 
and visually disabled and have seen that non-valid pages are almost 
impossible to parse for a screen reader.

This suggested diff generated patch adresses this, and makes the file HTML4.01 
Transitional valid. I have changed nothing in the content (Except removing 
the "Generated by Microsoft Frontpage tag... ).

If someone with CVS access could apply this after testing it, it would be 
great.

Thank you,
Lars Westergren

Re: [Junit-devel] Getting source by CVS

[Jean-Pierre M. <Jea...@in...>]

It works now. I think it was a tempory problem with whole sourceforge=20
site...

Jean-Pierre

Le 23 nov. 04, =E0 16:48, Jean-Pierre Matsumoto a =E9crit :
>
>  - web-based CVS repository viewer seems broken. I got no response.
>
>  - cvs login didn't work for me. I got error message "cvs login:=20
> authorization failed: server cvs.sourceforge.net rejected access to=20
> /cvsroot/junit for user anonymous" after to have use empty password.

---
Jean-Pierre Matsumoto
Jea...@in...