Menu
▾
▴
junit-devel — junit developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(80) |
Nov
(42) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(11) |
Feb
(50) |
Mar
(70) |
Apr
(102) |
May
(28) |
Jun
(45) |
Jul
(14) |
Aug
(75) |
Sep
(17) |
Oct
(15) |
Nov
(11) |
Dec
(4) |
| 2003 |
Jan
(16) |
Feb
(19) |
Mar
(21) |
Apr
(20) |
May
(29) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(3) |
| 2004 |
Jan
(5) |
Feb
(4) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(1) |
Dec
(2) |
| 2005 |
Jan
(4) |
Feb
(4) |
Mar
(15) |
Apr
(1) |
May
|
Jun
(4) |
Jul
(6) |
Aug
(6) |
Sep
|
Oct
(4) |
Nov
(2) |
Dec
(4) |
| 2006 |
Jan
|
Feb
(91) |
Mar
(47) |
Apr
(7) |
May
(4) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(5) |
Oct
(36) |
Nov
(95) |
Dec
(12) |
| 2007 |
Jan
(11) |
Feb
(31) |
Mar
(45) |
Apr
(11) |
May
(9) |
Jun
(1) |
Jul
(146) |
Aug
(15) |
Sep
|
Oct
(3) |
Nov
(6) |
Dec
(1) |
| 2008 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(2) |
Aug
(19) |
Sep
(1) |
Oct
(10) |
Nov
|
Dec
(8) |
| 2009 |
Jan
(3) |
Feb
(1) |
Mar
(4) |
Apr
(8) |
May
(5) |
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(13) |
Nov
(13) |
Dec
(4) |
| 2010 |
Jan
(1) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
(1) |
Feb
(4) |
Mar
(3) |
Apr
(4) |
May
|
Jun
(12) |
Jul
(16) |
Aug
(4) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
|
From: David S. <da...@sa...> - 2009-04-16 13:44:45
|
All, Just a heads-up: until the latest release, we've been applying a little effort to keep the JUnit CVS repository up to date with the changes happening on github. We're now applying changes exclusively on github: http://github.com/KentBeck/junit We'll be adding some sort of very-visible __README__ comment to the sourceforge CVS repository soon. Thanks, David Saff |
|
From: David S. <da...@sa...> - 2009-04-14 13:13:00
|
All, JUnit 4.6 is now released! There are a few bug fixes included, and improvements to the core architecture that allow test reordering and parallelization for basic JUnit 3 and basic JUnit 4 tests and suites. For details, please see the release notes. Release notes: https://sourceforge.net/project/shownotes.php?release_id=675664&group_id=15278 Download: https://sourceforge.net/project/showfiles.php?group_id=15278&package_id=12472 Share and Enjoy, Kent Beck and David Saff |
|
From: lukewpatterson <luk...@gm...> - 2009-04-10 14:34:53
|
On Thu, Apr 9, 2009 at 3:19 PM, Mike Forsberg <bi...@io...> wrote: > ... exposing JUnit as a service ... > I'll clarify the level of OSGi support I'm referring to. I was only hoping for compliance with the modularity/classloading portion of the OSGi spec, not the dynamic services portion. JUnit would not code to any OSGi API. No JUnit API would change. Existing consumer code which compiles to JUnit wouldn't need to change. The "modularity/classloading" portion I referred to above basically means that JUnit just needs proper OSGi entries added to the META-INF/manifest.mf. With the proper entries, the JUnit jar would become a "bundle" in the OSGi world. A "bundle" is basically a "module". i.e. a module contains packages, packages contain classes, classes contain fields/methods The manifest would explicitly declare (at the module level), which java packages JUnit imports (depends on) and which java packages JUnit exports (provides to others). In order for the JUnit jar to be considered a first-class citizen (can import/export packages directly) in the OSGi world, it needs to have valid manifest entries. Currently, when other projects are running in an OSGi container, they can't directly run against the official JUnit jar. They must custom-wrap the JUnit jar so its packages can be available at runtime. If you have some free minutes, please consider reading sections 1 through 1.4.3 of Neil Bartlett's "OSGi in practice" book [1]. I think he explains the core concepts pretty well (a lot better than I could). Thanks, Luke [1] http://neilbartlett.name/blog/osgibook/ -- View this message in context: http://www.nabble.com/OSGi-ify-JUnit---bug-2720888-tp22976430p22988877.html Sent from the JUnit - Dev mailing list archive at Nabble.com. |
|
From: Stephen S. <st...@st...> - 2009-04-09 21:01:15
|
I'm interested in having this discussion, but like Mike I'm a little puzzled as to the problem we're trying to solve. In addition to use cases, could someone provide some tests? Big Steve. Mike Forsberg wrote: > I heard alot about OSGi as of late... many developers at work seem to be > behind it as a system. I will say that I've very little knowlege of the > subject. > > However, from what I have seen/heard... OSGi is in the > interprocess/service communication space. To that extent, I really > don't see how I'd ever want my tests framework to be exposed as a > service. Maybe I'm wrong here, I'd love to hear arguments for it. > > Could someone provide some simple use cases, where exposing JUnit as a > service would provide some value. > > Big Mike > > On Thu, Apr 9, 2009 at 2:12 PM, lukewpatterson <luk...@gm... > <mailto:luk...@gm...>> wrote: > > > In bug 2720888 [1], David Saff recommended that I bring the > discussion to > this dev list. > > Please take a look at that bug to read the discussion so far... > basically, > I'm hoping that the current OSGi-ification work for JUnit can be > consolidated and brought into the core. > > I'm not trying to rush anyone to a decision. Please provide any > comments/feedback and I'll try to work through solutions for any > objections. > > Since JUnit is a core dependency of so many projects, I believe that > OSGi-ification will have a beneficial ripple effect. The barriers > to entry > will be lowered if the testing infrastructure is OSGi-ready. > > > Best Regards, > > Luke Patterson > > > [1] > http://sourceforge.net/tracker/?func=detail&aid=2720888&group_id=15278&atid=365278 > <http://sourceforge.net/tracker/?func=detail&aid=2720888&group_id=15278&atid=365278> > -- > View this message in context: > http://www.nabble.com/OSGi-ify-JUnit---bug-2720888-tp22976430p22976430.html > Sent from the JUnit - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Junit-devel mailing list > Jun...@li... > <mailto:Jun...@li...> > https://lists.sourceforge.net/lists/listinfo/junit-devel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.238 / Virus Database: 270.11.49/2050 - Release Date: 04/09/09 10:27:00 > |
|
From: Mike F. <bi...@io...> - 2009-04-09 20:19:46
|
I heard alot about OSGi as of late... many developers at work seem to be behind it as a system. I will say that I've very little knowlege of the subject. However, from what I have seen/heard... OSGi is in the interprocess/service communication space. To that extent, I really don't see how I'd ever want my tests framework to be exposed as a service. Maybe I'm wrong here, I'd love to hear arguments for it. Could someone provide some simple use cases, where exposing JUnit as a service would provide some value. Big Mike On Thu, Apr 9, 2009 at 2:12 PM, lukewpatterson <luk...@gm...>wrote: > > In bug 2720888 [1], David Saff recommended that I bring the discussion to > this dev list. > > Please take a look at that bug to read the discussion so far... basically, > I'm hoping that the current OSGi-ification work for JUnit can be > consolidated and brought into the core. > > I'm not trying to rush anyone to a decision. Please provide any > comments/feedback and I'll try to work through solutions for any > objections. > > Since JUnit is a core dependency of so many projects, I believe that > OSGi-ification will have a beneficial ripple effect. The barriers to entry > will be lowered if the testing infrastructure is OSGi-ready. > > > Best Regards, > > Luke Patterson > > > [1] > > http://sourceforge.net/tracker/?func=detail&aid=2720888&group_id=15278&atid=365278 > -- > View this message in context: > http://www.nabble.com/OSGi-ify-JUnit---bug-2720888-tp22976430p22976430.html > Sent from the JUnit - Dev mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > |
|
From: lukewpatterson <luk...@gm...> - 2009-04-09 19:12:36
|
In bug 2720888 [1], David Saff recommended that I bring the discussion to this dev list. Please take a look at that bug to read the discussion so far... basically, I'm hoping that the current OSGi-ification work for JUnit can be consolidated and brought into the core. I'm not trying to rush anyone to a decision. Please provide any comments/feedback and I'll try to work through solutions for any objections. Since JUnit is a core dependency of so many projects, I believe that OSGi-ification will have a beneficial ripple effect. The barriers to entry will be lowered if the testing infrastructure is OSGi-ready. Best Regards, Luke Patterson [1] http://sourceforge.net/tracker/?func=detail&aid=2720888&group_id=15278&atid=365278 -- View this message in context: http://www.nabble.com/OSGi-ify-JUnit---bug-2720888-tp22976430p22976430.html Sent from the JUnit - Dev mailing list archive at Nabble.com. |
|
From: David S. <da...@sa...> - 2009-04-07 03:18:14
|
JUnit 4.6 release candidate 1 is available. Please pound on it for a week, and let us know if there's any regressions Release notes: https://sourceforge.net/project/shownotes.php?release_id=674047&group_id=15278 Download: https://sourceforge.net/project/showfiles.php?group_id=15278&package_id=226053&release_id=674047 Share and Enjoy, Kent Beck and David Saff |
|
From: Chris S. <chr...@gm...> - 2009-03-25 15:40:59
|
Yes, I am running both from my laptop, one at a time. Same disk, o/s, jvm, etc. I'm using junit4 and ant 1.7.0 My goal is to deploy the ant script on a build server (where it is also running slowly) but for now, the 10x performance hit is on my Linux laptop. 2009/3/25 Hale,Katherine <ha...@oc...> > Chris - > > Was Eclipse running on the same machine you were executing the ANT script? > > Kathy > > ------------------------------ > *From:* Chris Stoughton [mailto:chr...@gm...] > *Sent:* Wednesday, March 25, 2009 11:09 AM > *To:* jun...@li... > *Subject:* [Junit-devel] eclipse vs. ant > > Tests run 10x slower in ant than in eclipse. Following the advice in these > posts: > http://marc.info/?t=116656587600001&r=1&w=2 > I have set fork="false" and maxmemory="1000m" in build.xml. > > Would there be another explanation for the slowness in ant builds? > > Thanks > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > > |
|
From: Hale,Katherine <ha...@oc...> - 2009-03-25 15:32:29
|
Chris - Was Eclipse running on the same machine you were executing the ANT script? Kathy ________________________________ From: Chris Stoughton [mailto:chr...@gm...] Sent: Wednesday, March 25, 2009 11:09 AM To: jun...@li... Subject: [Junit-devel] eclipse vs. ant Tests run 10x slower in ant than in eclipse. Following the advice in these posts: http://marc.info/?t=116656587600001&r=1&w=2 I have set fork="false" and maxmemory="1000m" in build.xml. Would there be another explanation for the slowness in ant builds? Thanks |
|
From: Chris S. <chr...@gm...> - 2009-03-25 15:09:17
|
Tests run 10x slower in ant than in eclipse. Following the advice in these posts: http://marc.info/?t=116656587600001&r=1&w=2 I have set fork="false" and maxmemory="1000m" in build.xml. Would there be another explanation for the slowness in ant builds? Thanks |
|
From: Chris S. <chr...@gm...> - 2009-03-25 15:08:48
|
Tests run 10x slower in ant than in eclipse. Following the advice in these posts: http://marc.info/?t=116656587600001&r=1&w=2 I have set fork="false" and maxmemory="1000m" in build.xml. Would there be another explanation for the slowness in ant builds? Thanks |
|
From: David S. <da...@sa...> - 2009-02-04 15:19:40
|
Nehal, Did you try googling for JUnit command line? David On Sat, Jan 17, 2009 at 9:25 AM, sowmya D.P <sow...@gm...> wrote: > Hi All, > > I have a netbeans project for which junit tests are developed and I > can run the the tests in Netbeans IDE. and I do used the ant to > generate a HTML report. > > Anyone can suggest me how to run/execute the tests in the command line. > > Please give me the detailed procedure to run in the command line. > > Thank you, > nehal > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > |
|
From: sowmya D.P <sow...@gm...> - 2009-01-17 14:25:11
|
Hi All, I have a netbeans project for which junit tests are developed and I can run the the tests in Netbeans IDE. and I do used the ant to generate a HTML report. Anyone can suggest me how to run/execute the tests in the command line. Please give me the detailed procedure to run in the command line. Thank you, nehal |
|
From: David S. <da...@sa...> - 2009-01-07 20:15:15
|
Amanda, Thanks for your patience. In general, patches should be attached to the respective bugs. Both patches (with changes) are now in HEAD. David Saff 2008/12/17 Amanda Robinson <ama...@gm...> > See attachments: > > DataPointPatch.txt: > fixes: AllMembersSupplier should only add @DataPoint fields - ID: 2191102 > Includes one added unit test to AnnotationTest.java > Includes update to AllMembersSupplier.addFields(ParameterSignature, > List<PotentialAssignment>) > Includes addition of @DataPoint annotation to every unit test that > appeared to require it, as some had used only 'public static' > > TheoriesPatch.txt: > fixes: @Theory annotation optional when running with Theories - ID: 2196462 > Includes three additional unit tests to AnnotationTest.java > Includes update to Theories.validateTestMethods(List<Throwable>) > > I couldn't find a way to put these files directly on SourceForge--I'm > assuming this has to do with various permissions, but if there's > somewhere to do this that I'm just not aware of and it would be > easier, please do point me in that direction. > > Thank you, > ~Amanda > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > > |
|
From: David S. <da...@sa...> - 2009-01-06 19:07:06
|
Iamkaihu, Thanks for writing this. Have you submitted it to the tools section at junit.org? If assumptions were reported as ignored, rather than passed, would you still say that junit-ext was needed in the base distribution? David Saff 2008/12/30 胡凯 <iam...@gm...> > Hi all: > In our project, I found there are many cases that we need to run tests only > when some prerequisites are satisfied(such as specific platform, specific > url can be reached and etc.), > > junit provided the assumption, it is great, however, I feel it has some > limitations(I addressed them in my project home page<http://code.google.com/p/junit-ext/> > .) > > I wrote a junit-ext to run test with @Prerequisites annotation, I host the > project here, http://code.google.com/p/junit-ext/ the code are tested > and used in my project everyday, I am quite happy to live with it, so I > think maybe other people may also want it. > > If you guys feel it is interesting. I will be really glad to contribute it > to junit > > Cheers > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > > |
|
From: 胡凯 <iam...@gm...> - 2008-12-30 14:08:47
|
Hi all: In our project, I found there are many cases that we need to run tests only when some prerequisites are satisfied(such as specific platform, specific url can be reached and etc.), junit provided the assumption, it is great, however, I feel it has some limitations(I addressed them in my project home page<http://code.google.com/p/junit-ext/> .) I wrote a junit-ext to run test with @Prerequisites annotation, I host the project here, http://code.google.com/p/junit-ext/ the code are tested and used in my project everyday, I am quite happy to live with it, so I think maybe other people may also want it. If you guys feel it is interesting. I will be really glad to contribute it to junit Cheers |
|
From: Amanda R. <ama...@gm...> - 2008-12-17 19:08:39
|
See attachments: DataPointPatch.txt: fixes: AllMembersSupplier should only add @DataPoint fields - ID: 2191102 Includes one added unit test to AnnotationTest.java Includes update to AllMembersSupplier.addFields(ParameterSignature, List<PotentialAssignment>) Includes addition of @DataPoint annotation to every unit test that appeared to require it, as some had used only 'public static' TheoriesPatch.txt: fixes: @Theory annotation optional when running with Theories - ID: 2196462 Includes three additional unit tests to AnnotationTest.java Includes update to Theories.validateTestMethods(List<Throwable>) I couldn't find a way to put these files directly on SourceForge--I'm assuming this has to do with various permissions, but if there's somewhere to do this that I'm just not aware of and it would be easier, please do point me in that direction. Thank you, ~Amanda |
|
From: David S. <da...@sa...> - 2008-12-17 17:59:31
|
Amanda, I think it's best to require @DataPoint, but we've been vague in the past. Some of the self-tests may need updating. Were there unit test failures before you started? Let's go ahead with two separate patches. David Saff On Wed, Dec 17, 2008 at 11:07 AM, Amanda Robinson <ama...@gm... > wrote: > I'm taking a look at the bug pasted below, in which not only > @DataPoint-annotated fields but all static fields in a > @RunWith(Theories.class) class are used as potential arguments for > @Theory methods. > > Is it correct that only fields with @DataPoint annotations should be > used? When I tried implementing a fix, all of a sudden there were > twice as many unit test failures overall. It looks like many of the > unit tests do not use the @DataPoint annotation for all fields they > expect to use in Theory methods. > > I've got a fix ready for bug 2196462, @Theory annotation optional when > running with Theories. Can I submit one patch to fix both that and > this bug, or is it best if I submit two separate patches? > > Thanks, > ~Amanda > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > |
|
From: Amanda R. <ama...@gm...> - 2008-12-17 16:07:57
|
I'm taking a look at the bug pasted below, in which not only @DataPoint-annotated fields but all static fields in a @RunWith(Theories.class) class are used as potential arguments for @Theory methods. Is it correct that only fields with @DataPoint annotations should be used? When I tried implementing a fix, all of a sudden there were twice as many unit test failures overall. It looks like many of the unit tests do not use the @DataPoint annotation for all fields they expect to use in Theory methods. I've got a fix ready for bug 2196462, @Theory annotation optional when running with Theories. Can I submit one patch to fix both that and this bug, or is it best if I submit two separate patches? Thanks, ~Amanda |
|
From: David S. <da...@sa...> - 2008-12-14 18:44:30
|
Mostly right, except that a @Test method with parameters should be flagged as invalid. Thanks for looking into this, David Saff On Sun, Dec 14, 2008 at 12:58 PM, Amanda Robinson <ama...@gm... > wrote: > The bug pasted below, @Theory annotation optional when running with > Theories, is currently unassigned. As long as nobody takes issue, I'm > going to dig into this a bit and hope to submit a patch soon. It > appears related to [ 2191102 ] AllMembersSupplier should only add > @DataPoint fields, so I may look into that bug as well. > > It appears that correct behavior is as follows: > - within a class annotated with @RunWith(Theories.class): > - any method annotated with @Theory should test all input > annotated with @DataPoint > - any method annotated with @Test should run as a standard test and > ignore > > Is this correct? If not, what is correct expected behavior? > > Thanks, > ~Amanda > > > > https://sourceforge.net/tracker/index.php?func=detail&aid=2196462&group_id=15278&atid=115278 > > Summary: (?) > @Theory annotation optional when running with Theories Private: (?) > No > The implementation of > org.junit.experimental.theories.Theories's computeTestMethods incorrectly > leaves @Test methods as @Theory methods. > > The following code: > @RunWith(Theories.class) > public class FooTest { > public static int VALUE=1; > @Test > public void bar(int i) { > System.out.println("bar:" +i); > > } > } > > Produces the result: bar:1 > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > |
|
From: Amanda R. <ama...@gm...> - 2008-12-14 17:58:21
|
The bug pasted below, @Theory annotation optional when running with
Theories, is currently unassigned. As long as nobody takes issue, I'm
going to dig into this a bit and hope to submit a patch soon. It
appears related to [ 2191102 ] AllMembersSupplier should only add
@DataPoint fields, so I may look into that bug as well.
It appears that correct behavior is as follows:
- within a class annotated with @RunWith(Theories.class):
- any method annotated with @Theory should test all input
annotated with @DataPoint
- any method annotated with @Test should run as a standard test and ignore
Is this correct? If not, what is correct expected behavior?
Thanks,
~Amanda
https://sourceforge.net/tracker/index.php?func=detail&aid=2196462&group_id=15278&atid=115278
Summary: (?)
@Theory annotation optional when running with Theories Private: (?)
No
The implementation of
org.junit.experimental.theories.Theories's computeTestMethods incorrectly
leaves @Test methods as @Theory methods.
The following code:
@RunWith(Theories.class)
public class FooTest {
public static int VALUE=1;
@Test
public void bar(int i) {
System.out.println("bar:" +i);
}
}
Produces the result: bar:1
|
|
From: David S. <da...@sa...> - 2008-12-11 17:27:25
|
Marián, Thanks for the bug report. I'm sorry that's never been fixed. Hopefully, we can avoid the same mistake in 4.6. David Saff On Thu, Aug 28, 2008 at 5:03 AM, Marián Petráš <Mar...@su...>wrote: > Hello, > > I found that the Javadoc published at > http://junit.org/junit/javadoc/4.5/ does contain the junit.framework.* > packages but the Javadoc contained in the published junit4.5.zip archive > does not contain these packages. Are there any plans to update the > Javadoc in junit4.5.zip archive? > > Thank you, > > Marián Petráš > NetBeans developer > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > |
|
From: David S. <da...@sa...> - 2008-12-03 15:03:21
|
[Adding junit-devel back in, whom I dropped off a while back]
Ah, yes. You may be glad or frustrated to know that Erich and I had a
discussion about this years ago, and decided that it would be quite
some time before it tripped anyone up. Welcome to the end of "quite
some time". :-)
I'd rather not make Description non-final. It's kind of the String of
JUnit--if people could suddenly, for example, create a subclass of
Description with a faulty equals() implementation, all hell would
break loose. Instead, I think that an optional "distinguisher" string
makes sense--Eclipse could display this or not, or make it optional,
but it would be used for hashCodes and comparisons.
If this makes sense for you, could you please raise an issue at
SourceForge? Thanks,
David
On Mon, Nov 24, 2008 at 4:02 PM, Mark Stobbe <mar...@ho...> wrote:
> David,
>
> Thanks for answering so quickly. I was explaining what I wanted to achieve
> but didn't
> mention the problem explicitly. It is indeed the hashcode which poses a
> problem. As the
> Description implementation uses only the name to generate an hashcode. In
> other words,
> when Eclipse creates the test/suite-tree it uses these hashcodes to lookup
> the item
> currently running.
>
> So assume i have test: "TestA" and "TestB", and both are in a different
> group:
>
> group1
> - TestA
> group2
> - TestB
>
> Then both hashcodes are different, so when TestA is started Eclipse will
> display this
> correctly by changing the icon. Now, assume the same configuration only this
> time
> TestB is also part of group1, i.e.:
>
> group1
> - TestA
> - TestB
> group2
> - TestB
>
> Everything is fine when I TestA starts, but when TestB starts it shows the
> TestB in group2
> as running, while it is actually the TestB in group1 which is running. So
> the problem is, they
> have the same hashcode. I see many solutions to this problem (at least for
> me it is), but
> I figured letting people subclass the Description class is the easiest to
> implement and pretty
> generic solution.
>
> However, other solutions include:
>
> - changing the requirements for a custom runner to allow Describeable
> interface implementation
> (not only Description)
> - improving the hashcode by including parent hashcodes
> - separating display name from actual name (i.e. name used by the hashcode)
>
> I hope that clears things,
> Mark.
>
>
>
>> Date: Mon, 24 Nov 2008 13:54:42 -0500
>> From: da...@sa...
>> To: mar...@ho...
>> Subject: Re: [Junit-devel] Extending the Description class
>>
>> Mark,
>>
>> Is the subclass in order to give the Description a different name? As
>> it stands, you can cheat (a little) by using
>> Description.createSuiteDescription("Any name you want"); Earlier,
>> though, you mentioned hashCode, so I'm thinking that what you actually
>> want is two tests that are recognized as different, but whose
>> Descriptions have the same name.
>>
>> Can you elaborate a little, so I make sure we're fixing the right
>> problem? Thanks,
>>
>> David Saff
>>
>> On Mon, Nov 24, 2008 at 12:31 PM, Mark Stobbe <mar...@ho...>
>> wrote:
>> > David,
>> >
>> > That's quite ok. The project as it is now is useable, its just that we
>> > would
>> > like to
>> > customize the description tree shown in Eclipse. At the moment we group
>> > all
>> > tests
>> > into one suite (group) and each test in this group gets the name + a
>> > numeric
>> > id.
>> >
>> > Disadvantage of this method is that we loose the reference to the
>> > correct
>> > method.
>> > Plus it might become weird when you have like "testMethod 23" in a group
>> > while all
>> > other 22 "testMethod"s are in different groups. Anyway, we will probably
>> > survive this,
>> > its just that it would be very nice to be able to subclass the
>> > Description
>> > class.
>> >
>> > At the moment its constructor is private, so it doesn't allow
>> > inheritance.
>> > I think thats
>> > the only thing that really needs to change. Either that or change the
>> > signature of the
>> > Runner (from the top of my head), to expect a Descriptable instead of an
>> > Description.
>> >
>> > Mark
>> >
>> >
>> >
>> >> Date: Mon, 24 Nov 2008 11:34:12 -0500
>> >> From: da...@sa...
>> >> To: mar...@ho...
>> >> Subject: Re: [Junit-devel] Extending the Description class
>> >>
>> >> Mark,
>> >>
>> >> I'm sorry I dropped off the grid on this conversation. I definitely
>> >> want to help your project succeed. Where do things stand now, more
>> >> than a month later? Thanks,
>> >>
>> >> David Saff
>> >>
>> >> 2008/10/14 Mark Stobbe <mar...@ho...>:
>> >> > David,
>> >> >
>> >> > I'm trying to implement different testing strategies using JUnit. So
>> >> > basically, I implemented my own Runner which collects custom
>> >> > annotations
>> >> > similar to the suite runner. Next I use this information to
>> >> > prioritize/group/etc tests in different ways. This allows me to still
>> >> > use
>> >> > the Eclipse plugin, while having my own JUnit extension.
>> >> >
>> >> > However, the problem I'm running into at the moment is that whenever
>> >> > I
>> >> > have
>> >> > two descriptions with the same display name, then they have the same
>> >> > hashcode. If you take things like "groups", then these descriptions
>> >> > do
>> >> > differ in my case because they are in different groups. One solution
>> >> > would
>> >> > be to prefix the description with the group name, but i would rather
>> >> > like to
>> >> > extend the description class and use the parent/child relations to
>> >> > model
>> >> > groups.
>> >> >
>> >> > So what's the problem? Well, if two descriptions have the same
>> >> > hashcode,
>> >> > then it becomes impossible for Eclipse to correctly show the
>> >> > running/finished/failed tests, because notification for description 1
>> >> > and 2
>> >> > are done on the same hashcode.
>> >> >
>> >> > I hope that explains the problem. My question is rather simple. Is it
>> >> > an
>> >> > option for the JUnit development team to make the Description
>> >> > constructor
>> >> > protected in their next release (or even better: nightly build).
>> >> >
>> >> > Thanks in advance,
>> >> > Mark
>> >> >
>> >> >
>> >> > ________________________________
>> >> >> Date: Tue, 14 Oct 2008 09:00:57 -0400
>> >> >> From: da...@sa...
>> >> >> To: mar...@ho...
>> >> >> Subject: Re: [Junit-devel] Extending the Description class
>> >> >> CC: jun...@li...
>> >> >>
>> >> >> Mark,
>> >> >>
>> >> >> I'd like to understand a little better what you're doing. Are you
>> >> >> fine-tuning the performance of a HashMap with Descriptions as keys?
>> >> >>
>> >> >> David Saff
>> >> >>
>> >> >> On Tue, Oct 14, 2008 at 3:02 AM, Mark Stobbe
>> >> >> <mar...@ho...>
>> >> >> wrote:
>> >> >> > Hello JUnit developer team,
>> >> >> >
>> >> >> > I have a question, or rather a request: could you make the
>> >> >> > constructor
>> >> >> > (and
>> >> >> > possibly the fields) of org.junit.runner.Description "protected"
>> >> >> > instead
>> >> >> > of
>> >> >> > "private". In this way it is impossible to normally subclass
>> >> >> > Description
>> >> >> > with a custom implementation.
>> >> >> >
>> >> >> > Why would you like to subclass Description? Well, the latest
>> >> >> > implementation
>> >> >> > of Description has a rather difficult hashCode implementation,
>> >> >> > namely:
>> >> >> > hashCode = getDisplayName().hashCode(). This poses a problem (or
>> >> >> > not,
>> >> >> > but in
>> >> >> > my case it does) when you create multiple instances of the
>> >> >> > Description
>> >> >> > class
>> >> >> > with the same name.
>> >> >> >
>> >> >> > Hopefully you are willing to incorporate this minor modification,
>> >> >> > it
>> >> >> > would
>> >> >> > surely make my life easier.
>> >> >> >
>> >> >> > Big thanks,
>> >> >> > Mark Stobbe
>> >> >> > ________________________________
>> >> >> > Plan je evenement, nodig mensen uit en deel je foto's met Windows
>> >> >> > Live
>> >> >> > Events
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > -------------------------------------------------------------------------
>> >> >> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>> >> >> > challenge
>> >> >> > Build the coolest Linux based applications with Moblin SDK & win
>> >> >> > great
>> >> >> > prizes
>> >> >> > Grand prize is a trip for two to an Open Source event anywhere in
>> >> >> > the
>> >> >> > world
>> >> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> >> >> > _______________________________________________
>> >> >> > Junit-devel mailing list
>> >> >> > Jun...@li...
>> >> >> > https://lists.sourceforge.net/lists/listinfo/junit-devel
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> > ________________________________
>> >> > Het beste van Windows, nu ook online. Deel jouw wereld met Windows
>> >> > Live.
>> >> > Download nu.
>> >> >
>> >> >
>> >> > -------------------------------------------------------------------------
>> >> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>> >> > challenge
>> >> > Build the coolest Linux based applications with Moblin SDK & win
>> >> > great
>> >> > prizes
>> >> > Grand prize is a trip for two to an Open Source event anywhere in the
>> >> > world
>> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> >> > _______________________________________________
>> >> > Junit-devel mailing list
>> >> > Jun...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/junit-devel
>> >> >
>> >> >
>> >
>> >
>> > ________________________________
>> > Plan je evenement, nodig mensen uit en deel je foto's met Windows Live
>> > Events
>
>
> ________________________________
> Chat met al je vrienden. Nodig ze nu uit voor Messenger!
|
|
From: Build A. <vim...@vi...> - 2008-10-28 20:13:48
|
BUILD result ------------------------------------------------------------ BUILD for JUnit (#163) on localhost was BROKEN: Script returned non-zero code "1" Build status: http://parabuild.viewtier.com:8080/parabuild/index.htm?view=detailed&buildid=5 Suspect Changes ------------------------------------------------------------ Change(s) by kbeck : - Eclipse isn't quite calling Max just yet. Keep sinning until; Time: 01:03 PM 10/28/2008; Change list: 14717 - AllTests passes, but Eclipse doesn't cal JUnitCore, so first; Time: 12:50 PM 10/28/2008; Change list: 14716 Change(s) Details: http://parabuild.viewtier.com:8080/parabuild/build/changes.htm?buildrunid=10855 BUILD logs ------------------------------------------------------------ BUILD log: http://parabuild.viewtier.com:8080/parabuild/build/log.htm?logid=15625 Error Lines: http://parabuild.viewtier.com:8080/parabuild/build/log.htm?logid=15626 Log Lines Around Error ------------------------------------------------------------ clean: [delete] Deleting directory /opt/parabuild/etc/build/b5co/a/u/t/o/junit/target init: versiontag: [copy] Copying 1 file to /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/junit/runner build: [mkdir] Created dir: /opt/parabuild/etc/build/b5co/a/u/t/o/junit/target/main [javac] Compiling 132 source files to /opt/parabuild/etc/build/b5co/a/u/t/o/junit/target/main [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/Request.java:14: package org.junit.tests.experimental.max does not exist [javac] import org.junit.tests.experimental.max.CouldNotReadCoreException; [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/Request.java:15: package org.junit.tests.experimental.max does not exist [javac] import org.junit.tests.experimental.max.MaxCore; [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:14: package org.junit.tests.experimental.max does not exist [javac] import org.junit.tests.experimental.max.CouldNotReadCoreException; [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:15: package org.junit.tests.experimental.max does not exist [javac] import org.junit.tests.experimental.max.MaxCore; [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/Request.java:64: cannot find symbol [javac] symbol: variable MaxCore [javac] MaxCore.forFolder("defaultMaxCore").run(delegate, core); [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/Request.java:65: cannot find symbol [javac] symbol: class CouldNotReadCoreException [javac] } catch (CouldNotReadCoreException e) { [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:141: cannot find symbol [javac] symbol : class MaxCore [javac] location: class org.junit.runner.JUnitCore [javac] MaxCore max= null; BUILD FAILED [javac] ^ /opt/parabuild/etc/build/b5co/a/u/t/o/junit/build.xml:74: The following error occurred while executing this line: [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:143: cannot find symbol /opt/parabuild/etc/build/b5co/a/u/t/o/junit/build.xml:67: Compile failed; see the compiler error output for details. [javac] symbol : variable MaxCore [javac] location: class org.junit.runner.JUnitCore Total time: 14 seconds [javac] max= MaxCore.forFolder("defaultMaxCore"); [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:144: cannot find symbol [javac] symbol : class CouldNotReadCoreException [javac] location: class org.junit.runner.JUnitCore [javac] } catch (CouldNotReadCoreException e) { [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 9 errors Timings ------------------------------------------------------------ BUILD took 18 seconds |
|
From: Build A. <vim...@vi...> - 2008-10-28 19:53:04
|
BUILD result ------------------------------------------------------------ BUILD for JUnit (#162) on localhost was BROKEN: Script returned non-zero code "1" Build status: http://parabuild.viewtier.com:8080/parabuild/index.htm?view=detailed&buildid=5 Suspect Changes ------------------------------------------------------------ Change(s) by kbeck : - AllTests passes, but Eclipse doesn't cal JUnitCore, so first; Time: 12:50 PM 10/28/2008; Change list: 14716 Change(s) Details: http://parabuild.viewtier.com:8080/parabuild/build/changes.htm?buildrunid=10853 BUILD logs ------------------------------------------------------------ BUILD log: http://parabuild.viewtier.com:8080/parabuild/build/log.htm?logid=15623 Error Lines: http://parabuild.viewtier.com:8080/parabuild/build/log.htm?logid=15624 Log Lines Around Error ------------------------------------------------------------ Buildfile: build.xml clean: [delete] Deleting directory /opt/parabuild/etc/build/b5co/a/u/t/o/junit/junit4.5 [delete] Deleting directory /opt/parabuild/etc/build/b5co/a/u/t/o/junit/target init: versiontag: [copy] Copying 1 file to /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/junit/runner build: [mkdir] Created dir: /opt/parabuild/etc/build/b5co/a/u/t/o/junit/target/main [javac] Compiling 132 source files to /opt/parabuild/etc/build/b5co/a/u/t/o/junit/target/main [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:14: package org.junit.tests.experimental.max does not exist [javac] import org.junit.tests.experimental.max.CouldNotReadCoreException; [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:15: package org.junit.tests.experimental.max does not exist [javac] import org.junit.tests.experimental.max.MaxCore; [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:141: cannot find symbol [javac] symbol : class MaxCore [javac] location: class org.junit.runner.JUnitCore [javac] MaxCore max= null; [javac] ^ [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:143: cannot find symbol BUILD FAILED [javac] symbol : variable MaxCore /opt/parabuild/etc/build/b5co/a/u/t/o/junit/build.xml:74: The following error occurred while executing this line: [javac] location: class org.junit.runner.JUnitCore /opt/parabuild/etc/build/b5co/a/u/t/o/junit/build.xml:67: Compile failed; see the compiler error output for details. [javac] max= MaxCore.forFolder("defaultMaxCore"); [javac] ^ Total time: 9 seconds [javac] /opt/parabuild/etc/build/b5co/a/u/t/o/junit/src/main/java/org/junit/runner/JUnitCore.java:144: cannot find symbol [javac] symbol : class CouldNotReadCoreException [javac] location: class org.junit.runner.JUnitCore [javac] } catch (CouldNotReadCoreException e) { [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 5 errors Timings ------------------------------------------------------------ BUILD took 10 seconds |
37 messages has been excluded from this view by a project administrator.
