Nabble - JUnit

Re: how to know if a test has failed

2009-12-07T07:41:16Z

> If you can use 4.7 or after, you're better off using a TestWatchman:
>
> http://kentbeck.github.com/junit/javadoc/4.8/org/junit/rules/TestWatchman.html
>
> Will that work for you?

I think so :)
Let me try to implement it that way.

thanks David.

--
Leo Arias. ¡paz y baile!
http://elopio.net

From forum: JUnit - User

Re: how to know if a test has failed

2009-12-07T05:56:59Z

Leo,

If you can use 4.7 or after, you're better off using a TestWatchman:

http://kentbeck.github.com/junit/javadoc/4.8/org/junit/rules/TestWatchman.html

Will that work for you?

David Saff

On Mon, Dec 7, 2009 at 12:09 AM, Leo Arias <yo@...> wrote:

> Hello,
>
> I want to execute some actions on @After only if the @Test has failed.
> Is there a function to know it a test has failed?
>
> thanks,
> pura vida.
>
> --
> Leo Arias. ¡paz y baile!
> http://elopio.net
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

From forum: JUnit - User

Re: Help need how to use JUnit tool in testing COBOL.

2009-12-07T05:55:47Z

Although, thanks for the impetus to learn something new to me:

http://sites.google.com/site/cobolunit/

David Saff

On Mon, Dec 7, 2009 at 6:27 AM, Ilja Preuß <iljapreuss@...> wrote:

> What's motivating you to use JUnit? Wouldn't it be better to write your
> tests in COBOL?
>
> 2009/12/6 conectme366 <conectme366@...>
>
>>
>>
>> Hi All,
>> This is Rocky.I need some help in testing COBOL using JUnit tool.Can anyone
>> provide some information / manual on this.
>> Thanks a lot in advance ,
>> Your information will be highly appreciated.
>> Best Regards,
>> Rocky.
>>
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

From forum: JUnit - User

Re: Help need how to use JUnit tool in testing COBOL.

2009-12-07T03:27:06Z

What's motivating you to use JUnit? Wouldn't it be better to write your
tests in COBOL?

2009/12/6 conectme366 <conectme366@...>

>
>
> Hi All,
> This is Rocky.I need some help in testing COBOL using JUnit tool.Can anyone
> provide some information / manual on this.
> Thanks a lot in advance ,
> Your information will be highly appreciated.
> Best Regards,
> Rocky.
>
>
>

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
junit-digest@...
junit-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
junit-unsubscribe@...

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

From forum: JUnit - User

how to know if a test has failed

2009-12-06T21:09:29Z

Hello,

I want to execute some actions on @After only if the @Test has failed.
Is there a function to know it a test has failed?

thanks,
pura vida.

--
Leo Arias. ¡paz y baile!
http://elopio.net

From forum: JUnit - User

Help need how to use JUnit tool in testing COBOL.

2009-12-05T18:34:56Z

Hi All,
This is Rocky.I need some help in testing COBOL using JUnit tool.Can anyone provide some information / manual on this.
Thanks a lot in advance ,
Your information will be highly appreciated.
Best Regards,
Rocky.

From forum: JUnit - User

Re: Global Rule, active for all tests

2009-12-05T11:46:56Z

Hi guys,

thank you very much for your responses.

I didn't know about the RunListener, so I will definitely take a look at it, and come back with an answer regarding it.

What I was thinking about the global rules is to be able to configure something like global rules, that are specified as a startup parameter (read Java option) when starting the test (in the project at my office, we have like 750 tests, and therefore would work just nice to configure this option just for my env; probably the RunListener will work just like that, so as I said, I will read about this).

I was thinking about something like this:

java -Djunit.globalRules=com.test.myrules.SomeNiceRule,com.test.myrules.SomeNiceRule2 ..........

Cheers,
Bogdan

--- In junit@..., "Bogdan" <bogdan.mocanu.notifications@...> wrote:

>
> Hi everyone,
>
> as we have it currently, we can place a Rule in a test, and that rule will be activated for that test. To have the rule working in several tests, you have to place the Rule in each test.
>
> However, I am searching for a way to activate a Rule for all the tests that are executed, without needing to add the rule to each test. Perhaps by specifying a Java property parameter when running the tests (I could also set this as a global Java option, therefore being used upon each execution of the JVM).
>
> Do you know if this is possible?
>
> The reason why I need this, is: I am making the plans and gathering the ideas for creating a simple Swing application that will display the results of the executed tests (just like the JUnit view in Eclipse/Idea/Netbeans, but perhaps with more details, and also available for anyone, not just IDE users). Currently I developed a small agent rule, that you can place in your test, and it will report to the console the status of your tests (the Swing console runs remotely).
>
> This is ok, but it means that you will have to add this rule to each and every test that you have. It also means that will not be an easy task to disable this rule, if you don't want it anymore.
>
> Therefore a possibility to enable Rules globally for all tests I think is the best solution for my case, and also a good tool to have for various other tasks.
>
> What do you think? Also, what do you think about the Swing console idea?
>
> Cheers,
> Bogdan
>

From forum: JUnit - User

Re: Global Rule, active for all tests

2009-12-05T10:43:06Z

All,

I understand global rules operationally not denotationally. If JUnit is a programming language, what do global rules *mean*?

Kent

On Dec 5, 2009, at 2:57 AM, David Saff wrote:

> Bogdan,
>
> Just this week, we were discussing a similar issue with global rules,
> inspired partly by Daniel's patch, so further votes would make a
> difference.
>
> That said, it sounds like a RunListener would give you what you need
> without any new JUnit extension.
>
> David Saff
>
> On Fri, Dec 4, 2009 at 10:34 AM, Bogdan
> <bogdan.mocanu.notifications@...> wrote:
> > Hi everyone,
> >
> > as we have it currently, we can place a Rule in a test, and that rule will be activated for that test. To have the rule working in several tests, you have to place the Rule in each test.
> >
> > However, I am searching for a way to activate a Rule for all the tests that are executed, without needing to add the rule to each test. Perhaps by specifying a Java property parameter when running the tests (I could also set this as a global Java option, therefore being used upon each execution of the JVM).
> >
> > Do you know if this is possible?
> >
> > The reason why I need this, is: I am making the plans and gathering the ideas for creating a simple Swing application that will display the results of the executed tests (just like the JUnit view in Eclipse/Idea/Netbeans, but perhaps with more details, and also available for anyone, not just IDE users). Currently I developed a small agent rule, that you can place in your test, and it will report to the console the status of your tests (the Swing console runs remotely).
> >
> > This is ok, but it means that you will have to add this rule to each and every test that you have. It also means that will not be an easy task to disable this rule, if you don't want it anymore.
> >
> > Therefore a possibility to enable Rules globally for all tests I think is the best solution for my case, and also a good tool to have for various other tasks.
> >
> > What do you think? Also, what do you think about the Swing console idea?
> >
> > Cheers,
> > Bogdan
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

From forum: JUnit - User

Re: Global Rule, active for all tests

2009-12-05T04:45:07Z

I just posted a *somewhat* similar question in regard to the JUnit runner in
Eclipse. I would like to have an "after" test that is run after all other
tests (no matter what tests you are running, single class, package or
project). This is because I have set up an
Thread.setDefaultUncaughtExceptionHandler that will pick up if threads die
unexpectedly (and I do that by a "before" logic that relies on a static
block in ALL tests, which obviously also would be nice if I could place in a
"before" test, harness). I want this "after" test to check that this number
is 0, and if not, fail the test.

It sounds slightly like this magic-all-tests-add Rule thing could fix my
problem - if the Eclipse runner honors this, of course. Just wanted to
mention it, if some tools in the future could take it into account!

Thanks,
Endre.

On Fri, Dec 4, 2009 at 16:34, Bogdan
<bogdan.mocanu.notifications@...>wrote:

>
>
> Hi everyone,
>
> as we have it currently, we can place a Rule in a test, and that rule will
> be activated for that test. To have the rule working in several tests, you
> have to place the Rule in each test.
>
> However, I am searching for a way to activate a Rule for all the tests that
> are executed, without needing to add the rule to each test. Perhaps by
> specifying a Java property parameter when running the tests (I could also
> set this as a global Java option, therefore being used upon each execution
> of the JVM).
>
> Do you know if this is possible?
>
> The reason why I need this, is: I am making the plans and gathering the
> ideas for creating a simple Swing application that will display the results
> of the executed tests (just like the JUnit view in Eclipse/Idea/Netbeans,
> but perhaps with more details, and also available for anyone, not just IDE
> users). Currently I developed a small agent rule, that you can place in your
> test, and it will report to the console the status of your tests (the Swing
> console runs remotely).
>
> This is ok, but it means that you will have to add this rule to each and
> every test that you have. It also means that will not be an easy task to
> disable this rule, if you don't want it anymore.
>
> Therefore a possibility to enable Rules globally for all tests I think is
> the best solution for my case, and also a good tool to have for various
> other tasks.
>
> What do you think? Also, what do you think about the Swing console idea?
>
> Cheers,
> Bogdan
>
>
>

[Non-text portions of this message have been removed]

From forum: JUnit - User

Re: Global Rule, active for all tests

2009-12-05T02:57:16Z

Bogdan,

Just this week, we were discussing a similar issue with global rules,
inspired partly by Daniel's patch, so further votes would make a
difference.

That said, it sounds like a RunListener would give you what you need
without any new JUnit extension.

David Saff

On Fri, Dec 4, 2009 at 10:34 AM, Bogdan
<bogdan.mocanu.notifications@...> wrote:

> Hi everyone,
>
> as we have it currently, we can place a Rule in a test, and that rule will be activated for that test. To have the rule working in several tests, you have to place the Rule in each test.
>
> However, I am searching for a way to activate a Rule for all the tests that are executed, without needing to add the rule to each test. Perhaps by specifying a Java property parameter when running the tests (I could also set this as a global Java option, therefore being used upon each execution of the JVM).
>
> Do you know if this is possible?
>
> The reason why I need this, is: I am making the plans and gathering the ideas for creating a simple Swing application that will display the results of the executed tests (just like the JUnit view in Eclipse/Idea/Netbeans, but perhaps with more details, and also available for anyone, not just IDE users). Currently I developed a small agent rule, that you can place in your test, and it will report to the console the status of your tests (the Swing console runs remotely).
>
> This is ok, but it means that you will have to add this rule to each and every test that you have. It also means that will not be an easy task to disable this rule, if you don't want it anymore.
>
> Therefore a possibility to enable Rules globally for all tests I think is the best solution for my case, and also a good tool to have for various other tasks.
>
> What do you think? Also, what do you think about the Swing console idea?
>
> Cheers,
> Bogdan
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

From forum: JUnit - User

Re: Global Rule, active for all tests

2009-12-05T02:27:50Z

Hi Bogdan,

I have kind of the same wish, and I have created an issue for it:
http://github.com/KentBeck/junit/issues#issue/40

I have also created a fork with an implementation of the functionality
(based on JUnit 4.7, I haven't had time to merge it with the latest). It
requires you to put your tests in a suite, add the rule on the suite and
annotate the rule for propagation to all sub-suites and tests.

I'm not sure this is exactely what you want, but if it is, you can help by
voting it up it might make it to some future release of JUnit. :-)

Cheers
Daniel

On Fri, Dec 4, 2009 at 4:34 PM, Bogdan <
bogdan.mocanu.notifications@...> wrote:

--
---------------------------------------------------------
Daniel Brolund
Agical AB - www.agical.com

work: daniel.brolund@...
phone: +46708754002
blog:http://danielbrolund.wordpress.com
twitter: @danielbrolund
private: daniel.brolund@...

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
junit-digest@...
junit-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
junit-unsubscribe@...

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

From forum: JUnit - User

Global Rule, active for all tests

2009-12-04T07:34:02Z

Hi everyone,

as we have it currently, we can place a Rule in a test, and that rule will be activated for that test. To have the rule working in several tests, you have to place the Rule in each test.

However, I am searching for a way to activate a Rule for all the tests that are executed, without needing to add the rule to each test. Perhaps by specifying a Java property parameter when running the tests (I could also set this as a global Java option, therefore being used upon each execution of the JVM).

Do you know if this is possible?

The reason why I need this, is: I am making the plans and gathering the ideas for creating a simple Swing application that will display the results of the executed tests (just like the JUnit view in Eclipse/Idea/Netbeans, but perhaps with more details, and also available for anyone, not just IDE users). Currently I developed a small agent rule, that you can place in your test, and it will report to the console the status of your tests (the Swing console runs remotely).

This is ok, but it means that you will have to add this rule to each and every test that you have. It also means that will not be an easy task to disable this rule, if you don't want it anymore.

Therefore a possibility to enable Rules globally for all tests I think is the best solution for my case, and also a good tool to have for various other tasks.

What do you think? Also, what do you think about the Swing console idea?

Cheers,
Bogdan

From forum: JUnit - User

Re: Re: JUnit 4.8 is released

2009-12-04T05:57:57Z

Greg,

Definitely sounds like a problem. Can you create a small example? Thanks,

David Saff

On Fri, Dec 4, 2009 at 2:11 AM, gregomena <gregomena@...> wrote:

> I've been testing. And everything is great when the annotation is in methods, but when it's in the class, tests are not executed.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

From forum: JUnit - User

Re: JUnit 4.8 is released

2009-12-03T23:11:32Z

I've been testing. And everything is great when the annotation is in methods, but when it's in the class, tests are not executed.

From forum: JUnit - User

Re: -Djava.ext.dirs issue?

2009-12-03T13:10:10Z

Hi David,

This has been logged as issue #59.

Thanks,
Bruce

--- In junit@..., David Saff <david@...> wrote:

>
> Bruce,
>
> This is actually a bug. Can you log it at github? Thanks,
>
> David Saff
>
> On Mon, Nov 30, 2009 at 10:52 AM, Bruce <bcowan12@...> wrote:
> > Hi,
> >
> > I have a problem where if I specify the java "ext" directory, JUnit is unable to find my test class. Whereas, if I just use "classpath", everything is fine. Since my tests will ultimately depend on a number of 3rd party libraries, I really want to just use the "ext" directory approach.
> >
> > For example:
> >
> > java -classpath /home/cowan/src/atst/lib/java/classes -Djava.ext.dirs=/home/cowan/src/atst/lib/java/ext org.junit.runner.JUnitCore atst.cs.test.TestAll
> >
> > this ends up with
> > JUnit version 4.7
> > Could not find class: atst.cs.test.TestAll
> >
> > The strange thing is that if I use the verbose flag on java, it even logs that it successfully loaded the TestAll class from the appropriate directory before later displaying the error.
> >
> > If I modify the command line to:
> >
> > java -classpath /home/cowan/src/atst/lib/java/classes:/home/cowan/tools/junit4.7/junit.jar org.junit.runner.JUnitCore atst.cs.test.TestAll
> >
> > everything works as expected.
> >
> > Does anyone know why -Djava.ext.dirs seems to cause JUnit to malfunction? (I've only tried this with JUnit 4.7)
> >
> > Thanks,
> > Bruce
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

From forum: JUnit - User

Re: -Djava.ext.dirs issue?

2009-12-03T08:28:35Z

Bruce,

This is actually a bug. Can you log it at github? Thanks,

David Saff

On Mon, Nov 30, 2009 at 10:52 AM, Bruce <bcowan12@...> wrote:

> Hi,
>
> I have a problem where if I specify the java "ext" directory, JUnit is unable to find my test class. Whereas, if I just use "classpath", everything is fine. Since my tests will ultimately depend on a number of 3rd party libraries, I really want to just use the "ext" directory approach.
>
> For example:
>
> java -classpath /home/cowan/src/atst/lib/java/classes -Djava.ext.dirs=/home/cowan/src/atst/lib/java/ext org.junit.runner.JUnitCore atst.cs.test.TestAll
>
> this ends up with
> JUnit version 4.7
> Could not find class: atst.cs.test.TestAll
>
> The strange thing is that if I use the verbose flag on java, it even logs that it successfully loaded the TestAll class from the appropriate directory before later displaying the error.
>
> If I modify the command line to:
>
> java -classpath /home/cowan/src/atst/lib/java/classes:/home/cowan/tools/junit4.7/junit.jar org.junit.runner.JUnitCore atst.cs.test.TestAll
>
> everything works as expected.
>
> Does anyone know why -Djava.ext.dirs seems to cause JUnit to malfunction? (I've only tried this with JUnit 4.7)
>
> Thanks,
> Bruce
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

From forum: JUnit - User

Re: JUnit 4.8 is released

2009-12-02T20:09:34Z

Thanks for your prompt response. - Sai

On Thu, Dec 3, 2009 at 9:12 AM, David Saff <david@...> wrote:

>
>
> [bcc: junit-announce]
>
> That's a bit of a documentation bug: the example code was developed as
> inner classes, and I didn't edit out the "static" modifiers. Will
> fix.
>
> David Saff
>
>
> On Tue, Dec 1, 2009 at 8:47 PM, B. Sai Prasad, M.Phil, SCJP, MCP,
> MCTS, SSGB, PMP, PMI-SP <sai.prasad.b@... <sai.prasad.b%40gmail.com>>
> wrote:
> > Hi David -
> >
> > New feature - Categories - will help developers to selectively group and
> > execute test classes and methods.
> >
> > I was looking at the releasnotes4.8.html, and found the classes are
> static.
> > Any reason why it should be static?
> >
> > Regards
> > Sai
> >
> > On Wed, Dec 2, 2009 at 2:33 AM, David Saff <david@...<david%40saff.net>>
> wrote:
> >
> >>
> >>
> >> JUnit 4.8 has been released. The primary new feature is preliminary
> >> support for Categories. For more information, see the release notes at
> >>
> >> http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html
> >>
> >> and the javadoc at
> >>
> >> http://kentbeck.github.com/junit/javadoc/4.8/
> >>
> >> and download from
> >>
> >> http://github.com/KentBeck/junit/downloads
> >>
> >> Share and Enjoy,
> >>
> >> David Saff
> >>
> >>
> >
> >
> >
> > --
>
> > What am I doing now? Visit http://twitter.com/saipower
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>

[Non-text portions of this message have been removed]

From forum: JUnit - User

Re: Bug reports?

2009-12-02T19:45:26Z

Bruce,

This is generally a good place to start, in case someone knows a fix
or workaround. The official bug list is at
http://github.com/KentBeck/junit/issues.

That said, I just got this message and your previous message nearly
simultaneously, so I think it was moderation lag (a human has to
approve first-time posts, to keep down spam.)

David Saff

On Wed, Dec 2, 2009 at 10:35 AM, Bruce <bcowan12@...> wrote:

> Hi,
>
> Where should I submit a bug report for JUnit? I wrote one up for this group a couple of days ago, but it never appeared. Other messages have been posted since, so I'm assuming that I've posted it in the wrong spot.
>
> Thanks,
> Bruce
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

From forum: JUnit - User

Re: JUnit 4.8 is released

2009-12-02T19:42:33Z

[bcc: junit-announce]

That's a bit of a documentation bug: the example code was developed as
inner classes, and I didn't edit out the "static" modifiers. Will
fix.

David Saff

On Tue, Dec 1, 2009 at 8:47 PM, B. Sai Prasad, M.Phil, SCJP, MCP,
MCTS, SSGB, PMP, PMI-SP <sai.prasad.b@...> wrote:

From forum: JUnit - User

Re: [junit] JUnit 4.8 is released

2009-12-02T19:42:33Z

> Hi David -
>
> New feature - Categories - will help developers to selectively group and
> execute test classes and methods.
>
> I was looking at the releasnotes4.8.html, and found the classes are static.
> Any reason why it should be static?
>
> Regards
> Sai
>
> On Wed, Dec 2, 2009 at 2:33 AM, David Saff <david@...> wrote:
>
>>
>>
>> JUnit 4.8 has been released. The primary new feature is preliminary
>> support for Categories. For more information, see the release notes at
>>
>> http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html
>>
>> and the javadoc at
>>
>> http://kentbeck.github.com/junit/javadoc/4.8/
>>
>> and download from
>>
>> http://github.com/KentBeck/junit/downloads
>>
>> Share and Enjoy,
>>
>> David Saff
>>
>>
>
>
>
> --
> What am I doing now? Visit http://twitter.com/saipower
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
> http://groups.yahoo.com/group/junit/
>
> <*> Your email settings:
> Individual Email | Traditional
>
> <*> To change settings online go to:
> http://groups.yahoo.com/group/junit/join
> (Yahoo! ID required)
>
> <*> To change settings via email:
> junit-digest@...
> junit-fullfeatured@...
>
> <*> To unsubscribe from this group, send an email to:
> junit-unsubscribe@...
>
> <*> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Junit-devel mailing list
Junit-devel@...
https://lists.sourceforge.net/lists/listinfo/junit-devel

From forum: JUnit - Dev

Bug reports?

2009-12-02T07:35:46Z

Hi,

Where should I submit a bug report for JUnit? I wrote one up for this group a couple of days ago, but it never appeared. Other messages have been posted since, so I'm assuming that I've posted it in the wrong spot.

Thanks,
Bruce

From forum: JUnit - User

Re: JUnit 4.8 is released

2009-12-01T19:23:03Z

From forum: JUnit - User

Re: [junit] JUnit 4.8 is released

2009-12-01T19:23:03Z

On Wed, Dec 2, 2009 at 5:03 AM, David Saff <david@...> wrote:
> JUnit 4.8 has been released. The primary new feature is preliminary
> support for Categories.

> download from
>
> http://github.com/KentBeck/junit/downloads

Congratulations and thanks! Hope it gets on the Maven repos soon...

- alistair

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Junit-devel mailing list
Junit-devel@...
https://lists.sourceforge.net/lists/listinfo/junit-devel

From forum: JUnit - Dev

Re: JUnit 4.8 is released

2009-12-01T17:47:01Z

Hi David -

New feature - Categories - will help developers to selectively group and
execute test classes and methods.

I was looking at the releasnotes4.8.html, and found the classes are static.
Any reason why it should be static?

Regards
Sai

On Wed, Dec 2, 2009 at 2:33 AM, David Saff <david@...> wrote:

>
>
> JUnit 4.8 has been released. The primary new feature is preliminary
> support for Categories. For more information, see the release notes at
>
> http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html
>
> and the javadoc at
>
> http://kentbeck.github.com/junit/javadoc/4.8/
>
> and download from
>
> http://github.com/KentBeck/junit/downloads
>
> Share and Enjoy,
>
> David Saff
>
>

--
What am I doing now? Visit http://twitter.com/saipower

[Non-text portions of this message have been removed]

From forum: JUnit - User

JUnit 4.8 is released

2009-12-01T13:03:14Z

From forum: JUnit - User

JUnit 4.8 is released

2009-12-01T13:03:14Z

JUnit 4.8 has been released. The primary new feature is preliminary
support for Categories. For more information, see the release notes at

http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html

and the javadoc at

http://kentbeck.github.com/junit/javadoc/4.8/

and download from

http://github.com/KentBeck/junit/downloads

Share and Enjoy,

David Saff

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Junit-announce mailing list
Junit-announce@...
https://lists.sourceforge.net/lists/listinfo/junit-announce

From forum: JUnit - Announce

JUnit 4.8 is released

2009-12-01T13:03:14Z

JUnit 4.8 has been released. The primary new feature is preliminary
support for Categories. For more information, see the release notes at

http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html

and the javadoc at

http://kentbeck.github.com/junit/javadoc/4.8/

and download from

http://github.com/KentBeck/junit/downloads

Share and Enjoy,

David Saff

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Junit-devel mailing list
Junit-devel@...
https://lists.sourceforge.net/lists/listinfo/junit-devel

From forum: JUnit - Dev

Re: Categories in JUnit 4.8

2009-11-30T15:32:28Z

I think that is a great point. It may often be more practical to tag tests for exclusion, based on execution time or external resource constraints than to tag fast tests.

I found it easier to use assumptions to exclude such tests, because I can state the assumption in a setup class that sets up the intensive resource and have the unit test automatically excluded just for writing it, but I can definitely see categories being a good exclusion mechanism.

--- In junit@..., "Pigneri, Rocco" <rpigneri@...> wrote:

>
> >> But group exclusion has other uses, such as "running all the tests except
> >> the slow ones", "excluding the ui tests", "excluding the Linux tests",
> >> etc...
> >
> > <snip>
> >
> >Got it. So we seem in agreement that excluded categories may be
> >useful, but a "broken" category is not the best argument for them.
>
> I also agree. I almost exclusively use categories to exclude certain types of tests, such as database tests, slow tests, integration tests, etc. from my main test run. In fact, for me, putting tests into a category is an exception rather than a rule: in other words, I only mark tests that I would *not* want to execute on each run of the test suite. All other tests get run on every run, each time.
>
> Hope that helps,
>
> Rocco
>
> From: junit@... [mailto:junit@...] On Behalf Of David Saff
> Sent: Sunday, November 22, 2009 10:53 PM
> To: junit@...
> Subject: Re: [junit] Re: Categories in JUnit 4.8
>
>
>
> 2009/11/22 CÃ©dric Beust â" <cbeust@...<mailto:cbeust%40google.com>>:
> > On Sun, Nov 22, 2009 at 7:36 PM, David Saff <david@...<mailto:david%40saff.net>> wrote:
> >
> >>
> >> > The problem with @Ignore is that 1) you need to specify it on all the
> >> > methods you want to exclude and 2) it forces a recompilation.
> >> >
> >> > Being able to specify "-ignore broken" at runtime allows you to exclude
> >> > dozens of methods in one single command.
> >>
> >> This story makes sense to me if you have many tests in the broken
> >> group, and sometimes want to run all of them, and sometimes want to
> >> run none of them. Is that your frequent experience? If so, I agree
> >> that excludable categories would be the way to do it.
> >>
> >
> > No, I never really run all the methods in the excluded groups, most of the
> > time, their purpose is just to be excluded. When I want to start fixing the
> > broken tests, I look at all the tests in that group and I take them out of
> > it one by one as I fix them.
> >
> > But group exclusion has other uses, such as "running all the tests except
> > the slow ones", "excluding the ui tests", "excluding the Linux tests",
> > etc...
> >
> > Admittedly, this is more on the integration/functional than on the unit test
> > side, so you might consider these out of scope for JUnit.
>
> Got it. So we seem in agreement that excluded categories may be
> useful, but a "broken" category is not the best argument for them.
>
> David Saff
>
> >
> >
> >> In my frequent experience, I tend to never run all the tests in the
> >> "broken" set: I enable them one by one, and fix them, when I can, so
> >> @Ignore works fine for me.
> >>
> >
> > That's also my experience for the Broken category.
> >
> > --
> > ***CÃ©dric
> > *
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>

From forum: JUnit - User

RE: Re: Categories in JUnit 4.8

2009-11-30T13:58:42Z

>> But group exclusion has other uses, such as "running all the tests except
>> the slow ones", "excluding the ui tests", "excluding the Linux tests",
>> etc...
>
> <snip>
>
>Got it. So we seem in agreement that excluded categories may be
>useful, but a "broken" category is not the best argument for them.

I also agree. I almost exclusively use categories to exclude certain types of tests, such as database tests, slow tests, integration tests, etc. from my main test run. In fact, for me, putting tests into a category is an exception rather than a rule: in other words, I only mark tests that I would *not* want to execute on each run of the test suite. All other tests get run on every run, each time.

Hope that helps,

Rocco

From: junit@... [mailto:junit@...] On Behalf Of David Saff
Sent: Sunday, November 22, 2009 10:53 PM
To: junit@...
Subject: Re: [junit] Re: Categories in JUnit 4.8

2009/11/22 Cédric Beust ♔ <cbeust@...<mailto:cbeust%40google.com>>:

> On Sun, Nov 22, 2009 at 7:36 PM, David Saff <david@...<mailto:david%40saff.net>> wrote:
>
>>
>> > The problem with @Ignore is that 1) you need to specify it on all the
>> > methods you want to exclude and 2) it forces a recompilation.
>> >
>> > Being able to specify "-ignore broken" at runtime allows you to exclude
>> > dozens of methods in one single command.
>>
>> This story makes sense to me if you have many tests in the broken
>> group, and sometimes want to run all of them, and sometimes want to
>> run none of them. Is that your frequent experience? If so, I agree
>> that excludable categories would be the way to do it.
>>
>
> No, I never really run all the methods in the excluded groups, most of the
> time, their purpose is just to be excluded. When I want to start fixing the
> broken tests, I look at all the tests in that group and I take them out of
> it one by one as I fix them.
>
> But group exclusion has other uses, such as "running all the tests except
> the slow ones", "excluding the ui tests", "excluding the Linux tests",
> etc...
>
> Admittedly, this is more on the integration/functional than on the unit test
> side, so you might consider these out of scope for JUnit.

Got it. So we seem in agreement that excluded categories may be
useful, but a "broken" category is not the best argument for them.

David Saff

>
>
>> In my frequent experience, I tend to never run all the tests in the
>> "broken" set: I enable them one by one, and fix them, when I can, so
>> @Ignore works fine for me.
>>
>
> That's also my experience for the Broken category.
>
> --
> ***Cédric
> *
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]

From forum: JUnit - User

-Djava.ext.dirs issue?

2009-11-30T07:52:33Z

Hi,

I have a problem where if I specify the java "ext" directory, JUnit is unable to find my test class. Whereas, if I just use "classpath", everything is fine. Since my tests will ultimately depend on a number of 3rd party libraries, I really want to just use the "ext" directory approach.

For example:

java -classpath /home/cowan/src/atst/lib/java/classes -Djava.ext.dirs=/home/cowan/src/atst/lib/java/ext org.junit.runner.JUnitCore atst.cs.test.TestAll

this ends up with
JUnit version 4.7
Could not find class: atst.cs.test.TestAll

The strange thing is that if I use the verbose flag on java, it even logs that it successfully loaded the TestAll class from the appropriate directory before later displaying the error.

If I modify the command line to:

java -classpath /home/cowan/src/atst/lib/java/classes:/home/cowan/tools/junit4.7/junit.jar org.junit.runner.JUnitCore atst.cs.test.TestAll

everything works as expected.

Does anyone know why -Djava.ext.dirs seems to cause JUnit to malfunction? (I've only tried this with JUnit 4.7)

Thanks,
Bruce

From forum: JUnit - User

Re: Big abstract class test, Test Suite and JUnit 4 problem

2009-11-27T08:24:28Z

--- In junit@..., "Fedy2" <fedy2@...> wrote:

>
>
>
> --- In junit@..., Mike Forsberg <bigmike@> wrote:
> >
> > I wonder why you are extending TestCase if you are using annotations?
> > Extending the TestCase class is the old 3.x way of doing things.
>
>
> I needed it to put my test classes into a testsuite. The addTest method accept only Test interface implementations.

To cite an earlier post: this is the old way of doing things. Annotate the suite-to-be with @RunWith(Suite.class)
and @SuiteClasses(...)
The test classes then neither need to extend some class or any annotation other than @Test for the methods initiating the tests.
You may even look into the new 4.8 featue : categories.

Cheers,
Georg

From forum: JUnit - User

Re: Big abstract class test, Test Suite and JUnit 4 problem

2009-11-26T21:47:34Z

Hi!

TestCase is just a compatibility feature from earlier versions of Junit. You likely want to do the following:
place only the common things into the abstract class T (you can use annotation there).
Place the test-specifics into T1, T2,... and introduce a Suite
comprising T1, T2,...

OR is there a reason why you cannot refactor T into smaller parts?

As for applying tests to different classes implementing the same interface, look at parametrized tests. I used this in JLinAlg. You may need, though, a factories for A and B implementing a common interface F.

Ho this hleps,
Georg

--- In junit@..., "Fedy2" <fedy2@...> wrote:

>
> Hi all,
>
> I have this situation:
> A big interface "I" which is implemented by the "A" and "B" classes.
>
> I've solved the problem of wrote only one test for both implementations using the method described here:
>
> http://c2.com/cgi/wiki?AbstractTestCases
>
> So I have an abstract class "T" with all methods test for "I" annotated as JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
>
>
> Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I want to collect it under a common test suite "TS".
>
> I have tried this solution:
> "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances to the test suite.
> But this solution don't work because "T1" need to extend TestCase and in "T1" I'm using JUnit 4 annotations.
>
> Any idea how to solve the problem?
>
> Thanks
> Federico
>

From forum: JUnit - User

Re: Big abstract class test, Test Suite and JUnit 4 problem

2009-11-26T15:53:29Z

--- In junit@..., Mike Forsberg <bigmike@...> wrote:
>
> I wonder why you are extending TestCase if you are using annotations?
> Extending the TestCase class is the old 3.x way of doing things.

I needed it to put my test classes into a testsuite. The addTest method accept only Test interface implementations.

Now,
> you only need to implement a method and annotate it with @Test to make
> a test method.
>
> Also I don't know why you are constructing instances of the tests...

For pass it the Interface implementation to test.

>
> If you'd like more help I'll write up a snippet of code and post it to
> the mailing list.
>
> Big Mike

I think your article is OK.

Thanks
Federico

>
> On Thu, Nov 26, 2009 at 3:11 AM, Fedy2 <fedy2@...> wrote:
> > Hi all,
> >
> > I have this situation:
> > A big interface "I" which is implemented by the "A" and "B" classes.
> >
> > I've solved the problem of wrote only one test for both implementations using the method described here:
> >
> > http://c2.com/cgi/wiki?AbstractTestCases
> >
> > So I have an abstract class "T" with all methods test for "I" annotated as JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
> >
> >
> > Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I want to collect it under a common test suite "TS".
> >
> > I have tried this solution:
> > "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances to the test suite.
> > But this solution don't work because "T1" need to extend TestCase and in "T1" I'm using JUnit 4 annotations.
> >
> > Any idea how to solve the problem?
> >
> > Thanks
> > Federico
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

From forum: JUnit - User

Re: Big abstract class test, Test Suite and JUnit 4 problem

2009-11-26T15:40:22Z

Hi Big Mike,
thanks for your article. Your solution is for sure an answer to my problem.

There is an aspect that I don't like, with that solution I need to instantiate an interface implementation ("A","B".. classes) for each test class. That was the reason why I was trying to put all test classes in a test suite, anyway this is not a big problem.

Thanks.
Federico

--- In junit@..., Mike Forsberg <bigmike.f@...> wrote:

>
> I just posted some sample code about this topic on my blog.
>
> It will be a more polished response in the future, but for now take a look.
>
> http://bigmikef.blogspot.com/2009/11/reply-to-junit-mailing-list-about.html
>
> Big Mike
>
> On Thu, Nov 26, 2009 at 2:23 PM, Mike Forsberg <bigmike@...> wrote:
> > I wonder why you are extending TestCase if you are using annotations?
> > Extending the TestCase class is the old 3.x way of doing things. Now,
> > you only need to implement a method and annotate it with @Test to make
> > a test method.
> >
> > Also I don't know why you are constructing instances of the tests...
> >
> > If you'd like more help I'll write up a snippet of code and post it to
> > the mailing list.
> >
> > Big Mike
> >
> > On Thu, Nov 26, 2009 at 3:11 AM, Fedy2 <fedy2@...> wrote:
> >> Hi all,
> >>
> >> I have this situation:
> >> A big interface "I" which is implemented by the "A" and "B" classes.
> >>
> >> I've solved the problem of wrote only one test for both implementations using the method described here:
> >>
> >> http://c2.com/cgi/wiki?AbstractTestCases
> >>
> >> So I have an abstract class "T" with all methods test for "I" annotated as JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
> >>
> >>
> >> Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I want to collect it under a common test suite "TS".
> >>
> >> I have tried this solution:
> >> "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances to the test suite.
> >> But this solution don't work because "T1" need to extend TestCase and in "T1" I'm using JUnit 4 annotations.
> >>
> >> Any idea how to solve the problem?
> >>
> >> Thanks
> >> Federico
> >>
> >>
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >
>

From forum: JUnit - User

Re: Big abstract class test, Test Suite and JUnit 4 problem

2009-11-26T13:21:20Z

I just posted some sample code about this topic on my blog.

It will be a more polished response in the future, but for now take a look.

http://bigmikef.blogspot.com/2009/11/reply-to-junit-mailing-list-about.html

Big Mike

On Thu, Nov 26, 2009 at 2:23 PM, Mike Forsberg <bigmike@...> wrote:

> I wonder why you are extending TestCase if you are using annotations?
> Extending the TestCase class is the old 3.x way of doing things. Now,
> you only need to implement a method and annotate it with @Test to make
> a test method.
>
> Also I don't know why you are constructing instances of the tests...
>
> If you'd like more help I'll write up a snippet of code and post it to
> the mailing list.
>
> Big Mike
>
> On Thu, Nov 26, 2009 at 3:11 AM, Fedy2 <fedy2@...> wrote:
>> Hi all,
>>
>> I have this situation:
>> A big interface "I" which is implemented by the "A" and "B" classes.
>>
>> I've solved the problem of wrote only one test for both implementations using the method described here:
>>
>> http://c2.com/cgi/wiki?AbstractTestCases
>>
>> So I have an abstract class "T" with all methods test for "I" annotated as JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
>>
>>
>> Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I want to collect it under a common test suite "TS".
>>
>> I have tried this solution:
>> "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances to the test suite.
>> But this solution don't work because "T1" need to extend TestCase and in "T1" I'm using JUnit 4 annotations.
>>
>> Any idea how to solve the problem?
>>
>> Thanks
>> Federico
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>

From forum: JUnit - User