Menu
▾
▴
junit-trackers — Lots of tracker notifications
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(38) |
Apr
(23) |
May
(16) |
Jun
(6) |
Jul
(49) |
Aug
(11) |
Sep
(2) |
Oct
(12) |
Nov
(9) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(3) |
Feb
(9) |
Mar
(16) |
Apr
(15) |
May
(20) |
Jun
(3) |
Jul
(22) |
Aug
(32) |
Sep
(22) |
Oct
(17) |
Nov
(8) |
Dec
(9) |
| 2009 |
Jan
(5) |
Feb
(3) |
Mar
(15) |
Apr
(51) |
May
(23) |
Jun
(11) |
Jul
(9) |
Aug
(10) |
Sep
(8) |
Oct
(11) |
Nov
(130) |
Dec
(105) |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:12
|
Bugs item #2845605, was opened at 2009-08-27 14:43 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2845605&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: test runner Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Peter Hale (peternhale) Assigned to: Nobody/Anonymous (nobody) Summary: Assume.assume* functions do not mark the test as ignored Initial Comment: I have some tests which only make sense to run if an object passed into the test is not null. Using the Assume.assumeNotNull seems like the sensible approach to controlling test execution, however, after the test has run there seems to be no way to distinguish between a test that was halted via assumeNotNull and one that passed. Given the test class: @RunWith(Parameterized.class) public class IgnoreThis { @Parameters public static List<Object[]> data() { return Arrays.asList(new Object[][]{{null}, {"not null"}}); } private Object o; public IgnoreThis(Object input) { this.o = input; } @Test public void assumeTrueIgnoredTest() { assumeNotNull(o); assertNotNull(o); } @Ignore @Test public void annotationIgnoredTest() { } } I was actually expecting the test which was halted by assumeNotNull to be reported differently than a test that passed. I may be reading too much into the javadoc, but it seems that using the Assume methods would yield the same reporting results as using the @Ignore annotation. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-01 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:45 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2845605&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:12
|
Bugs item #2814222, was opened at 2009-06-29 20:28 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2814222&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: framework Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Kristian Rosenvold (krosenvold) Assigned to: Nobody/Anonymous (nobody) Summary: Concurrency problem in Result.java Initial Comment: Result.java is riddled with unsafepublications. Enclosed patch fixes it. Enclosed failing test fails on my 8 core i7 all of the time when run from idea. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-01 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:46 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Kristian Rosenvold (krosenvold) Date: 2009-06-30 10:05 Message: The testcase fails most of the time, but not always;) It never fails after applying the patch though ;) Sorry for being chatty here ;) ---------------------------------------------------------------------- Comment By: Kristian Rosenvold (krosenvold) Date: 2009-06-30 09:30 Message: The new patch uses java 5 concurrency features. Much nicer ;) ---------------------------------------------------------------------- Comment By: Kristian Rosenvold (krosenvold) Date: 2009-06-29 20:33 Message: Re-reading my initial patch makes me think it's still not totally thread safe. Additional patch should do the trick. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2814222&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:12
|
Bugs item #2796455, was opened at 2009-05-25 14:38 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2796455&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: framework Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Markus Keller (make) Assigned to: Nobody/Anonymous (nobody) Summary: Javadoc of Parameterized is garbled Initial Comment: Since 4.5, the Javadoc of class Parameterized is garbled: http://www.junit.org/junit/javadoc/4.5/org/junit/runners/Parameterized.html Try to compile the example and you see what I mean. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-01 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:47 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2796455&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:12
|
Bugs item #2797957, was opened at 2009-05-28 15:02 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2797957&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: test runner Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Paul Lyon (pmlyon) Assigned to: Nobody/Anonymous (nobody) Summary: Running single parameterized test method from Eclipse fails Initial Comment: If you attempt to run a single test method on a parameterized test from Eclipse, it fails. The Parameterized.testName method returns a test method name like "methodName[0]". The test then fails when it attempts to run the method called "methodName[0]" instead of just "methodName". ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-01 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:46 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2797957&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:12
|
Bugs item #2841770, was opened at 2009-08-21 08:58 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2841770&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: test runner Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: ~TraydenT~ (traydent) Assigned to: Nobody/Anonymous (nobody) Summary: Assumptions fails with ExpectedExceptions Initial Comment: When yo have a method annotated with @Test(expected = SomeException.class) and when this method contains a failing call to assumeTrue (or other Assume.assume* static method), the test fails because of unexpected error. The attached source is not supposed to fail, but it fails. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-01 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:46 Message: Sorry, that's http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:45 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2841770&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-21 14:44:15
|
Bugs item #2900304, was opened at 2009-11-19 15:49 Message generated for change (Comment added) made by jasonngyl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2900304&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: framework Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Jason Ng Yong Liang (jasonngyl) Assigned to: Nobody/Anonymous (nobody) Summary: TestWatchman and Verifier should be abstract Initial Comment: Was implementing TestWatchman and realised that the class is not abstract but yet does nothing when used. Both TestWatchman and Verifier should be made abstract like ExternalResource, to clearly document that they are meant to be extended and not to be used as it is. ---------------------------------------------------------------------- Comment By: Jason Ng Yong Liang (jasonngyl) Date: 2009-11-21 22:44 Message: Ok, logged at GitHub. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-19 22:30 Message: Sounds good to me. We're decommisioning the trackers here. Can you log this at http://github.com/KentBeck/junit/issues, so we don't miss it? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2900304&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-20 20:18:35
|
Bugs item #2900304, was opened at 2009-11-19 02:49 Message generated for change (Settings changed) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2900304&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: framework Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Jason Ng Yong Liang (jasonngyl) Assigned to: Nobody/Anonymous (nobody) Summary: TestWatchman and Verifier should be abstract Initial Comment: Was implementing TestWatchman and realised that the class is not abstract but yet does nothing when used. Both TestWatchman and Verifier should be made abstract like ExternalResource, to clearly document that they are meant to be extended and not to be used as it is. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-19 09:30 Message: Sounds good to me. We're decommisioning the trackers here. Can you log this at http://github.com/KentBeck/junit/issues, so we don't miss it? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2900304&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-20 16:29:52
|
Feature Requests item #1941834, was opened at 2008-04-14 04:22 Message generated for change (Comment added) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1941834&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Thomas Steininger (steininger) Assigned to: Nobody/Anonymous (nobody) Summary: additional Parameter for the @Test - invocationCount Initial Comment: Please support invocationCount as an additional Parameter for the @Test-Annotation. I think this would be easy and useful. Additionally it would be useful to add successPercentage too. (like TestNG) ---------------------------------------------------------------------- >Comment By: David Saff (dsaff) Date: 2009-11-20 11:29 Message: Please continue the conversation at github! Thanks. ---------------------------------------------------------------------- Comment By: Thomas Steininger (steininger) Date: 2009-11-20 03:05 Message: Additionally it would be very useful to add the Parameter threadPoolSize too. So it is easily possible to test the method under the situation of multiple callings from different threads. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-18 14:29 Message: Copied at http://github.com/KentBeck/junit/issues/#issue/50 Two issue trackers was one too many, sorry. ---------------------------------------------------------------------- Comment By: Thomas Steininger (steininger) Date: 2009-11-17 02:42 Message: + why this tracker will be closed? + i don't have accounts (and dont know how to get) to reenter my request there. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Thomas Steininger (steininger) Date: 2008-04-14 04:29 Message: Logged In: YES user_id=1323884 Originator: YES Additionally it would be very useful to add the Parameter threadPoolSize too. So it is easily possible to test the method under the situation of multiple callings from different threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1941834&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-20 08:05:11
|
Feature Requests item #1941834, was opened at 2008-04-14 08:22 Message generated for change (Comment added) made by steininger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1941834&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Steininger (steininger) Assigned to: Nobody/Anonymous (nobody) Summary: additional Parameter for the @Test - invocationCount Initial Comment: Please support invocationCount as an additional Parameter for the @Test-Annotation. I think this would be easy and useful. Additionally it would be useful to add successPercentage too. (like TestNG) ---------------------------------------------------------------------- >Comment By: Thomas Steininger (steininger) Date: 2009-11-20 08:05 Message: Additionally it would be very useful to add the Parameter threadPoolSize too. So it is easily possible to test the method under the situation of multiple callings from different threads. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-18 19:29 Message: Copied at http://github.com/KentBeck/junit/issues/#issue/50 Two issue trackers was one too many, sorry. ---------------------------------------------------------------------- Comment By: Thomas Steininger (steininger) Date: 2009-11-17 07:42 Message: + why this tracker will be closed? + i don't have accounts (and dont know how to get) to reenter my request there. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Thomas Steininger (steininger) Date: 2008-04-14 08:29 Message: Logged In: YES user_id=1323884 Originator: YES Additionally it would be very useful to add the Parameter threadPoolSize too. So it is easily possible to test the method under the situation of multiple callings from different threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1941834&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-19 14:30:31
|
Bugs item #2900304, was opened at 2009-11-19 02:49 Message generated for change (Comment added) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2900304&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: framework Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Ng Yong Liang (jasonngyl) Assigned to: Nobody/Anonymous (nobody) Summary: TestWatchman and Verifier should be abstract Initial Comment: Was implementing TestWatchman and realised that the class is not abstract but yet does nothing when used. Both TestWatchman and Verifier should be made abstract like ExternalResource, to clearly document that they are meant to be extended and not to be used as it is. ---------------------------------------------------------------------- >Comment By: David Saff (dsaff) Date: 2009-11-19 09:30 Message: Sounds good to me. We're decommisioning the trackers here. Can you log this at http://github.com/KentBeck/junit/issues, so we don't miss it? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2900304&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-19 07:49:15
|
Bugs item #2900304, was opened at 2009-11-19 15:49 Message generated for change (Tracker Item Submitted) made by jasonngyl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2900304&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: framework Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Ng Yong Liang (jasonngyl) Assigned to: Nobody/Anonymous (nobody) Summary: TestWatchman and Verifier should be abstract Initial Comment: Was implementing TestWatchman and realised that the class is not abstract but yet does nothing when used. Both TestWatchman and Verifier should be made abstract like ExternalResource, to clearly document that they are meant to be extended and not to be used as it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=2900304&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-18 20:31:15
|
Feature Requests item #1550922, was opened at 2006-09-02 04:20 Message generated for change (Comment added) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1550922&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jesse Glick (jglick) Assigned to: Nobody/Anonymous (nobody) Summary: Assert should check types on Object Initial Comment: org.junit.Assert.assertEquals should have a signature such as public static <T> void assertEquals(T expected, T actual); rather than using (Object,Object). Similarly for the variant taking a message, of course. The additional typecheck would turn a dumb mistake such as this: List<String> names = ...; ... assertEquals(Collections.singleton("foo"), names); // ^^^^^^^^^ // should be: singletonList into a compile-time error, rather than the cryptic test failure message expected:<[foo]> but was:<[foo]> ---------------------------------------------------------------------- >Comment By: David Saff (dsaff) Date: 2009-11-18 15:31 Message: Thanks, Jesse ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2009-11-16 18:20 Message: commit de7ac4a1c3c7c9e59befe41d120daaa7827b7b24 Author: kbeck <kbeck> Date: Thu Feb 8 03:29:22 2007 +0000 Added class names to error message when two values fail the equality test but produce the same toString(). ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2009-11-16 18:11 Message: Seems JUnit 4.5 has already fixed this anyway: @Test public void compareTypes() { assertEquals(Collections.singleton(5), Arrays.asList(5)); } => expected: java.util.Collections$SingletonSet<[5]> but was: java.util.Arrays$ArrayList<[5]> ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2006-09-06 11:02 Message: Logged In: YES user_id=257383 Sets and lists are not considered equal. The example should have been corrected to e.g. assertEquals(Collections.singleton("foo"), new HashSet<String>(names)); I would like to see something like expected: java.util.ArrayList <[foo]> but was: java.util.Collections$SingletonSet <[foo]> ---------------------------------------------------------------------- Comment By: Matthias Schmidt (cmschmidt) Date: 2006-09-06 10:48 Message: Logged In: YES user_id=1523407 ARE a List and a Set not Comparable? Both are Collections resp. Iterables. Depending on your program, you would either have to compare their class types (1) or their content (2). Both is possible. 1: assertTrue( set.getClass() != list.getClass() ); 2: assertEquals(set.toArray(), list.toArray() ); Regarding your alternate strategy: I like the idea to enhance the error message to something like "List <[]> expected but was Set <[]>". Was it that what you meant? ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2006-09-06 09:55 Message: Logged In: YES user_id=257383 I meant to prevent a comparison between e.g. Set<String> and List<String>. Unfortunately it seems javac will just treat this as <Object>assertEquals(..., ...); which does not help anything. So it will not work. Alternate strategy: in assertEquals, if the args are not equal but their toString()s are equal, instead/additionally print the impl class (o.getClass().getName()) of each. That would at least clue you in to the fact that a List and a Set are not comparable. I could supply a patch if you want one, but it should be easy. ---------------------------------------------------------------------- Comment By: Matthias Schmidt (cmschmidt) Date: 2006-09-04 07:52 Message: Logged In: YES user_id=1523407 Are you sure there is a compile time error? I have rewritten the assertEquals method as you suggested and written a test like this: @Test public void stringTest() { List<String> names = new ArrayList<String>(); names.add("foo"); assertEquals(Collections.singleton("foo"), names); } and the failure message was "expected:<[foo]> but was:<[foo]>". So no real improvement here ;) I am not sure if I understand what kind of typecheck you would like to do. Is it to prevent to not be able to compare e.g. a Boolean to an ArrayList? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1550922&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-18 20:30:36
|
Feature Requests item #2816904, was opened at 2009-07-05 10:36 Message generated for change (Settings changed) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2816904&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Steven Buroff (sburoff) Assigned to: Nobody/Anonymous (nobody) Summary: Name parameterized test cases Initial Comment: Is there any way to attach a name to each test case in a parameterized test such that the name appears on the junit output? If not I'd like to request such a capability. Thanks. Steve Buroff sb...@op... ---------------------------------------------------------------------- >Comment By: David Saff (dsaff) Date: 2009-11-18 15:30 Message: I believe this is handled by http://github.com/KentBeck/junit/issues#issue/24. Sorry about any site problems with github: can you try again? ---------------------------------------------------------------------- Comment By: Steven Buroff (sburoff) Date: 2009-11-16 14:57 Message: I tried to comment at http://github.com/KentBeck/junit/issues but it just hung when I tried to submit the comment. ---------------------------------------------------------------------- Comment By: Steven Buroff (sburoff) Date: 2009-11-16 14:56 Message: I like the first alternative - call toString() on the first argument. Its simple and it makes the name available to the test if it wants it. Otherwise it can just ignore the first argument. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2816904&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-18 19:29:51
|
Feature Requests item #1941834, was opened at 2008-04-14 04:22 Message generated for change (Comment added) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1941834&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Thomas Steininger (steininger) Assigned to: Nobody/Anonymous (nobody) Summary: additional Parameter for the @Test - invocationCount Initial Comment: Please support invocationCount as an additional Parameter for the @Test-Annotation. I think this would be easy and useful. Additionally it would be useful to add successPercentage too. (like TestNG) ---------------------------------------------------------------------- >Comment By: David Saff (dsaff) Date: 2009-11-18 14:29 Message: Copied at http://github.com/KentBeck/junit/issues/#issue/50 Two issue trackers was one too many, sorry. ---------------------------------------------------------------------- Comment By: Thomas Steininger (steininger) Date: 2009-11-17 02:42 Message: + why this tracker will be closed? + i don't have accounts (and dont know how to get) to reenter my request there. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Thomas Steininger (steininger) Date: 2008-04-14 04:29 Message: Logged In: YES user_id=1323884 Originator: YES Additionally it would be very useful to add the Parameter threadPoolSize too. So it is easily possible to test the method under the situation of multiple callings from different threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1941834&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-17 12:37:07
|
Bugs item #1877429, was opened at 2008-01-22 10:00 Message generated for change (Comment added) made by sburoff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1877429&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Pending Resolution: None Priority: 4 Private: No Submitted By: Markus Keller (make) Assigned to: jsuchy (jsuchy) Summary: update Javadocs on www.junit.org Initial Comment: Latest Javadocs are not available any more on www.junit.org. They have once been made available (see bug 1555652), but currently, there's only http://junit.sourceforge.net/javadoc/ (looks like 3.8.?) and http://junit.sourceforge.net/javadoc_40/ (parts of 4.0) Please restore Javadocs at the old locations, i.e. http://www.junit.org/junit/javadoc/3.8.1/ and http://www.junit.org/junit/javadoc/4.3/ , and add the latest at http://www.junit.org/junit/javadoc/4.4/ ---------------------------------------------------------------------- Comment By: Steven Buroff (sburoff) Date: 2009-11-17 07:37 Message: I too would like all the javadocs to be available. The zip file for 4.7 does not contain the correct and complete javadocs. I don't understand why that was never fixed and why it seems that every release has an incorrect or incomplete javadoc. Given that it does however, it would seem an important requirement to make correct versions of the javadocs for the latest and several previous releases available at the junit web site. Currently I must generate the javadoc myself from the source and this involves editing the build file. That is an unwarranted waste of time and space. ---------------------------------------------------------------------- Comment By: Ian Robertson (iroberts) Date: 2009-11-16 17:55 Message: Created new ticket: http://github.com/KentBeck/junit/issues/#issue/48 ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:49 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Ian Robertson (iroberts) Date: 2009-08-24 14:04 Message: With the introduction of Rules, it would be very nice to see javadocs for 4.7. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-04-20 15:57 Message: James, Assigning to you. Let me know what you need. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-04-20 14:37 Message: We had caught up to JUnit 4.5, but now need to re-up to 4.6. James Suchy, webmaster, has been looped in. ---------------------------------------------------------------------- Comment By: CoSoCo (cosoco) Date: 2008-08-28 09:08 Message: Logged In: YES user_id=1040495 Originator: NO I also would like to have Javadocs from junit.framework.* packages included in junit4.5.zip, like they are nicely published at http://www.junit.org/junit/javadoc/4.5/ . Regards, Ulf ---------------------------------------------------------------------- Comment By: Marián Petráš (mpetras) Date: 2008-08-27 08:15 Message: Logged In: YES user_id=2187323 Originator: NO Javadoc that is packed in the released junit4.5.zip does not contain any junit.framework.* packages, but Javadoc published at http://www.junit.org/junit/javadoc/4.5/ does. ---------------------------------------------------------------------- Comment By: Markus Keller (make) Date: 2008-08-20 11:46 Message: Logged In: YES user_id=239537 Originator: YES > This is fixed. Please close. Something is there, but * http://www.junit.org/junit/javadoc/3.8.1/ - is incomplite, e.g. misses junit.runner, junit.textui, ... * http://www.junit.org/junit/javadoc/4.4/ - is incomplete: misses org.hamcrest, - contains non-API stuff, e.g. junit.tests, junit.samples * http://www.junit.org/junit/javadoc/4.5/ - is incomplete: misses org.hamcrest ---------------------------------------------------------------------- Comment By: Ben (bjrady) Date: 2008-08-19 23:34 Message: Logged In: YES user_id=1012272 Originator: NO This is fixed. Please close. ---------------------------------------------------------------------- Comment By: Markus Keller (make) Date: 2008-07-29 05:08 Message: Logged In: YES user_id=239537 Originator: YES Yesterday, http://www.junit.org/junit/javadoc/4.4/index.html was redirected to http://www.junit.org/junit/javadoc/4.3/index.html . Today, only the latter works. The former says "JUnit.org has undergone some changes...", and the link to "JavaDoc" in the header points to the outdated http://junit.sourceforge.net/javadoc_40/index.html . I have not found Javadocs for 4.4. http://www.junit.org/junit/javadoc/3.8.1/index.html is only partial (e.g. misses junit.runner and junit.textui). ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2008-01-25 12:33 Message: Logged In: YES user_id=325156 Originator: NO I've requested help from the junit.org webmaster. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1877429&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-17 07:42:36
|
Feature Requests item #1941834, was opened at 2008-04-14 08:22 Message generated for change (Comment added) made by steininger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1941834&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Steininger (steininger) Assigned to: Nobody/Anonymous (nobody) Summary: additional Parameter for the @Test - invocationCount Initial Comment: Please support invocationCount as an additional Parameter for the @Test-Annotation. I think this would be easy and useful. Additionally it would be useful to add successPercentage too. (like TestNG) ---------------------------------------------------------------------- >Comment By: Thomas Steininger (steininger) Date: 2009-11-17 07:42 Message: + why this tracker will be closed? + i don't have accounts (and dont know how to get) to reenter my request there. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Thomas Steininger (steininger) Date: 2008-04-14 08:29 Message: Logged In: YES user_id=1323884 Originator: YES Additionally it would be very useful to add the Parameter threadPoolSize too. So it is easily possible to test the method under the situation of multiple callings from different threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1941834&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 23:20:06
|
Feature Requests item #1550922, was opened at 2006-09-02 08:20 Message generated for change (Comment added) made by jglick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1550922&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jesse Glick (jglick) Assigned to: Nobody/Anonymous (nobody) Summary: Assert should check types on Object Initial Comment: org.junit.Assert.assertEquals should have a signature such as public static <T> void assertEquals(T expected, T actual); rather than using (Object,Object). Similarly for the variant taking a message, of course. The additional typecheck would turn a dumb mistake such as this: List<String> names = ...; ... assertEquals(Collections.singleton("foo"), names); // ^^^^^^^^^ // should be: singletonList into a compile-time error, rather than the cryptic test failure message expected:<[foo]> but was:<[foo]> ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2009-11-16 23:20 Message: commit de7ac4a1c3c7c9e59befe41d120daaa7827b7b24 Author: kbeck <kbeck> Date: Thu Feb 8 03:29:22 2007 +0000 Added class names to error message when two values fail the equality test but produce the same toString(). ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2009-11-16 23:11 Message: Seems JUnit 4.5 has already fixed this anyway: @Test public void compareTypes() { assertEquals(Collections.singleton(5), Arrays.asList(5)); } => expected: java.util.Collections$SingletonSet<[5]> but was: java.util.Arrays$ArrayList<[5]> ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2006-09-06 15:02 Message: Logged In: YES user_id=257383 Sets and lists are not considered equal. The example should have been corrected to e.g. assertEquals(Collections.singleton("foo"), new HashSet<String>(names)); I would like to see something like expected: java.util.ArrayList <[foo]> but was: java.util.Collections$SingletonSet <[foo]> ---------------------------------------------------------------------- Comment By: Matthias Schmidt (cmschmidt) Date: 2006-09-06 14:48 Message: Logged In: YES user_id=1523407 ARE a List and a Set not Comparable? Both are Collections resp. Iterables. Depending on your program, you would either have to compare their class types (1) or their content (2). Both is possible. 1: assertTrue( set.getClass() != list.getClass() ); 2: assertEquals(set.toArray(), list.toArray() ); Regarding your alternate strategy: I like the idea to enhance the error message to something like "List <[]> expected but was Set <[]>". Was it that what you meant? ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2006-09-06 13:55 Message: Logged In: YES user_id=257383 I meant to prevent a comparison between e.g. Set<String> and List<String>. Unfortunately it seems javac will just treat this as <Object>assertEquals(..., ...); which does not help anything. So it will not work. Alternate strategy: in assertEquals, if the args are not equal but their toString()s are equal, instead/additionally print the impl class (o.getClass().getName()) of each. That would at least clue you in to the fact that a List and a Set are not comparable. I could supply a patch if you want one, but it should be easy. ---------------------------------------------------------------------- Comment By: Matthias Schmidt (cmschmidt) Date: 2006-09-04 11:52 Message: Logged In: YES user_id=1523407 Are you sure there is a compile time error? I have rewritten the assertEquals method as you suggested and written a test like this: @Test public void stringTest() { List<String> names = new ArrayList<String>(); names.add("foo"); assertEquals(Collections.singleton("foo"), names); } and the failure message was "expected:<[foo]> but was:<[foo]>". So no real improvement here ;) I am not sure if I understand what kind of typecheck you would like to do. Is it to prevent to not be able to compare e.g. a Boolean to an ArrayList? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1550922&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 23:11:33
|
Feature Requests item #1550922, was opened at 2006-09-02 08:20 Message generated for change (Comment added) made by jglick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1550922&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jesse Glick (jglick) Assigned to: Nobody/Anonymous (nobody) Summary: Assert should check types on Object Initial Comment: org.junit.Assert.assertEquals should have a signature such as public static <T> void assertEquals(T expected, T actual); rather than using (Object,Object). Similarly for the variant taking a message, of course. The additional typecheck would turn a dumb mistake such as this: List<String> names = ...; ... assertEquals(Collections.singleton("foo"), names); // ^^^^^^^^^ // should be: singletonList into a compile-time error, rather than the cryptic test failure message expected:<[foo]> but was:<[foo]> ---------------------------------------------------------------------- >Comment By: Jesse Glick (jglick) Date: 2009-11-16 23:11 Message: Seems JUnit 4.5 has already fixed this anyway: @Test public void compareTypes() { assertEquals(Collections.singleton(5), Arrays.asList(5)); } => expected: java.util.Collections$SingletonSet<[5]> but was: java.util.Arrays$ArrayList<[5]> ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 17:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2006-09-06 15:02 Message: Logged In: YES user_id=257383 Sets and lists are not considered equal. The example should have been corrected to e.g. assertEquals(Collections.singleton("foo"), new HashSet<String>(names)); I would like to see something like expected: java.util.ArrayList <[foo]> but was: java.util.Collections$SingletonSet <[foo]> ---------------------------------------------------------------------- Comment By: Matthias Schmidt (cmschmidt) Date: 2006-09-06 14:48 Message: Logged In: YES user_id=1523407 ARE a List and a Set not Comparable? Both are Collections resp. Iterables. Depending on your program, you would either have to compare their class types (1) or their content (2). Both is possible. 1: assertTrue( set.getClass() != list.getClass() ); 2: assertEquals(set.toArray(), list.toArray() ); Regarding your alternate strategy: I like the idea to enhance the error message to something like "List <[]> expected but was Set <[]>". Was it that what you meant? ---------------------------------------------------------------------- Comment By: Jesse Glick (jglick) Date: 2006-09-06 13:55 Message: Logged In: YES user_id=257383 I meant to prevent a comparison between e.g. Set<String> and List<String>. Unfortunately it seems javac will just treat this as <Object>assertEquals(..., ...); which does not help anything. So it will not work. Alternate strategy: in assertEquals, if the args are not equal but their toString()s are equal, instead/additionally print the impl class (o.getClass().getName()) of each. That would at least clue you in to the fact that a List and a Set are not comparable. I could supply a patch if you want one, but it should be easy. ---------------------------------------------------------------------- Comment By: Matthias Schmidt (cmschmidt) Date: 2006-09-04 11:52 Message: Logged In: YES user_id=1523407 Are you sure there is a compile time error? I have rewritten the assertEquals method as you suggested and written a test like this: @Test public void stringTest() { List<String> names = new ArrayList<String>(); names.add("foo"); assertEquals(Collections.singleton("foo"), names); } and the failure message was "expected:<[foo]> but was:<[foo]>". So no real improvement here ;) I am not sure if I understand what kind of typecheck you would like to do. Is it to prevent to not be able to compare e.g. a Boolean to an ArrayList? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1550922&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 22:55:03
|
Bugs item #1877429, was opened at 2008-01-22 08:00 Message generated for change (Comment added) made by iroberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1877429&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Pending Resolution: None Priority: 4 Private: No Submitted By: Markus Keller (make) Assigned to: jsuchy (jsuchy) Summary: update Javadocs on www.junit.org Initial Comment: Latest Javadocs are not available any more on www.junit.org. They have once been made available (see bug 1555652), but currently, there's only http://junit.sourceforge.net/javadoc/ (looks like 3.8.?) and http://junit.sourceforge.net/javadoc_40/ (parts of 4.0) Please restore Javadocs at the old locations, i.e. http://www.junit.org/junit/javadoc/3.8.1/ and http://www.junit.org/junit/javadoc/4.3/ , and add the latest at http://www.junit.org/junit/javadoc/4.4/ ---------------------------------------------------------------------- Comment By: Ian Robertson (iroberts) Date: 2009-11-16 15:55 Message: Created new ticket: http://github.com/KentBeck/junit/issues/#issue/48 ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 10:49 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Ian Robertson (iroberts) Date: 2009-08-24 12:04 Message: With the introduction of Rules, it would be very nice to see javadocs for 4.7. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-04-20 13:57 Message: James, Assigning to you. Let me know what you need. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-04-20 12:37 Message: We had caught up to JUnit 4.5, but now need to re-up to 4.6. James Suchy, webmaster, has been looped in. ---------------------------------------------------------------------- Comment By: CoSoCo (cosoco) Date: 2008-08-28 07:08 Message: Logged In: YES user_id=1040495 Originator: NO I also would like to have Javadocs from junit.framework.* packages included in junit4.5.zip, like they are nicely published at http://www.junit.org/junit/javadoc/4.5/ . Regards, Ulf ---------------------------------------------------------------------- Comment By: Marián Petráš (mpetras) Date: 2008-08-27 06:15 Message: Logged In: YES user_id=2187323 Originator: NO Javadoc that is packed in the released junit4.5.zip does not contain any junit.framework.* packages, but Javadoc published at http://www.junit.org/junit/javadoc/4.5/ does. ---------------------------------------------------------------------- Comment By: Markus Keller (make) Date: 2008-08-20 09:46 Message: Logged In: YES user_id=239537 Originator: YES > This is fixed. Please close. Something is there, but * http://www.junit.org/junit/javadoc/3.8.1/ - is incomplite, e.g. misses junit.runner, junit.textui, ... * http://www.junit.org/junit/javadoc/4.4/ - is incomplete: misses org.hamcrest, - contains non-API stuff, e.g. junit.tests, junit.samples * http://www.junit.org/junit/javadoc/4.5/ - is incomplete: misses org.hamcrest ---------------------------------------------------------------------- Comment By: Ben (bjrady) Date: 2008-08-19 21:34 Message: Logged In: YES user_id=1012272 Originator: NO This is fixed. Please close. ---------------------------------------------------------------------- Comment By: Markus Keller (make) Date: 2008-07-29 03:08 Message: Logged In: YES user_id=239537 Originator: YES Yesterday, http://www.junit.org/junit/javadoc/4.4/index.html was redirected to http://www.junit.org/junit/javadoc/4.3/index.html . Today, only the latter works. The former says "JUnit.org has undergone some changes...", and the link to "JavaDoc" in the header points to the outdated http://junit.sourceforge.net/javadoc_40/index.html . I have not found Javadocs for 4.4. http://www.junit.org/junit/javadoc/3.8.1/index.html is only partial (e.g. misses junit.runner and junit.textui). ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2008-01-25 10:33 Message: Logged In: YES user_id=325156 Originator: NO I've requested help from the junit.org webmaster. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115278&aid=1877429&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 19:57:31
|
Feature Requests item #2816904, was opened at 2009-07-05 10:36 Message generated for change (Comment added) made by sburoff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2816904&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Buroff (sburoff) Assigned to: Nobody/Anonymous (nobody) Summary: Name parameterized test cases Initial Comment: Is there any way to attach a name to each test case in a parameterized test such that the name appears on the junit output? If not I'd like to request such a capability. Thanks. Steve Buroff sb...@op... ---------------------------------------------------------------------- >Comment By: Steven Buroff (sburoff) Date: 2009-11-16 14:57 Message: I tried to comment at http://github.com/KentBeck/junit/issues but it just hung when I tried to submit the comment. ---------------------------------------------------------------------- Comment By: Steven Buroff (sburoff) Date: 2009-11-16 14:56 Message: I like the first alternative - call toString() on the first argument. Its simple and it makes the name available to the test if it wants it. Otherwise it can just ignore the first argument. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2816904&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 19:56:20
|
Feature Requests item #2816904, was opened at 2009-07-05 10:36 Message generated for change (Comment added) made by sburoff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2816904&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steven Buroff (sburoff) Assigned to: Nobody/Anonymous (nobody) Summary: Name parameterized test cases Initial Comment: Is there any way to attach a name to each test case in a parameterized test such that the name appears on the junit output? If not I'd like to request such a capability. Thanks. Steve Buroff sb...@op... ---------------------------------------------------------------------- >Comment By: Steven Buroff (sburoff) Date: 2009-11-16 14:56 Message: I like the first alternative - call toString() on the first argument. Its simple and it makes the name available to the test if it wants it. Otherwise it can just ignore the first argument. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=2816904&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 18:57:44
|
Feature Requests item #1742040, was opened at 2007-06-23 08:51 Message generated for change (Comment added) made by anshnd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1742040&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Anli Shundi (anshnd) Assigned to: Nobody/Anonymous (nobody) Summary: Parameterized runner should include data in test names Initial Comment: Right now the test names are determined as follows in Parameterized: @Override protected String getName() { return String.format("[%s]", fParameterSetNumber); } @Override protected String testName(final Method method) { return String.format("%s[%s]", method.getName(), fParameterSetNumber); } It would help of the value of the first parameter was included in the name. Maybe Parameterized can be parameterized to contain the format for names? I can submit a patch if needed. ---------------------------------------------------------------------- Comment By: Anli Shundi (anshnd) Date: 2009-11-16 13:57 Message: Please vote at http://github.com/KentBeck/junit/issues/#issue/44 ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-06-03 04:43 Message: <a href="<http://groups.google.com/group/buy-best-generic-valium>">buy valium</a> ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-04-06 10:00 Message: Unfortunately, this is unlikely to make the cut for the 4.6 release, but I hope to integrate early in the 4.7 branch ---------------------------------------------------------------------- Comment By: Stefan Anzinger (sanzinger) Date: 2009-04-05 07:42 Message: Hi all, is there a plan to integrate such functionality in the next release. I did some search in the internet, a lot people facing the same problem. (See links below) Kind Regards Stefan https://sourceforge.net/mailarchive/forum.php?thread_name=4c9260f80809101330p1b822382v34f427ae73f8aafb%40mail.gmail.com&forum_name=junit-devel https://sourceforge.net/tracker/index.php?func=detail&atid=365278&aid=1742040&group_id=15278 https://sourceforge.net/tracker/index.php?func=detail&aid=1630834&group_id=15278&atid=365278 http://tech.groups.yahoo.com/group/junit/message/21425 http://contrapunctus.net/index.php/2006/parameterized-tests-in-junit-4 http://www.junit.org/node/506 http://stackoverflow.com/questions/650894/change-test-name-of-parameterized-tests ---------------------------------------------------------------------- Comment By: Henrik Kaipe (kaipe) Date: 2008-11-04 17:44 Message: I have implemented an alternative solution to this: https://sourceforge.net/tracker2/?func=detail&aid=2222651&group_id=15278&atid=365278 ---------------------------------------------------------------------- Comment By: Anli Shundi (anshnd) Date: 2008-10-14 15:09 Message: committing the patch. Hopefully this can be approved, applied and closed? File Added: Parameterized.patch ---------------------------------------------------------------------- Comment By: Anli Shundi (anshnd) Date: 2008-10-13 14:15 Message: I'm submitting a modified Parameterized.java with updated javadoc that gets the name by calling a public, static (!) method annotated by @TestName (new) and accepting the same arguments as the constructor. The method had to be static because the name is needed before the tests are instantiated. File Added: Parameterized.java ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-09-04 17:04 Message: Logged In: NO I agree that this definitely could be better, but would like to suggest a different approach: What if instead the ParameterizedRunner called .toString() on the newly allocated TestObject (Since the whole point of the parameterized test is to create one object per parameter set). This way programmers could have full control over the appearance. ---------------------------------------------------------------------- Comment By: Matthew Hall (qualidafial) Date: 2007-08-20 17:34 Message: Logged In: YES user_id=168544 Originator: NO +1 for @TestName ---------------------------------------------------------------------- Comment By: Jeremy Carroll (jeremy_carroll) Date: 2007-08-03 05:20 Message: Logged In: YES user_id=482628 Originator: NO This duplicates: http://sourceforge.net/tracker/index.php?func=detail&aid=1630834&group_id=15278&atid=365278 ---------------------------------------------------------------------- Comment By: Jeremy Carroll (jeremy_carroll) Date: 2007-08-03 05:16 Message: Logged In: YES user_id=482628 Originator: NO I would like this feature too. Using the first arg, while limiting, is better than no solution. ---------------------------------------------------------------------- Comment By: Anli Shundi (anshnd) Date: 2007-07-18 13:25 Message: Logged In: YES user_id=180255 Originator: YES Calling @TestName is good idea; what about when there's more than one test though? It makes sense to combine the value of TestName with the methodName (orginal test value). Also, a name like @ParameterizedTestname would be more suitable since this annotation wouldn't apply to normal @Test-s. Since we're at Parameterized. Can someone with write permission please commit this diff for a meaningful error message? RCS file: /cvsroot/junit/junit/src/org/junit/runners/Parameterized.java,v retrieving revision 1.5 diff -w -b -r1.5 Parameterized.java 87c87 < Assert.assertEquals(1, constructors.length); --- > Assert.assertEquals("Only one connstructor is allowed for tests run by Parameterized", 1, constructors.length); ---------------------------------------------------------------------- Comment By: dasblinkenlight (dasblinkenlight) Date: 2007-07-13 17:54 Message: Logged In: YES user_id=1827208 Originator: NO > It would help of the value of the first parameter was included in the name. I think that using the first parameter (A) is too limiting because it may not be a meaningful string, and (B) is not backward-compatible, because users will see "junk" names when their first argument is a class that does not override Object#toString. A better solution would be to have the TestClassRunnerForParameters call the method with @TestName annotation in the test class, if one is provided, and use the [%s] name by default. This way the users will have full control over the generation of test names, and the results will be 100% backward-compatible because @TestName annotation class does not exist yet. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2007-07-09 15:05 Message: Logged In: YES user_id=325156 Originator: NO Moved to feature requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1742040&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 18:56:21
|
Feature Requests item #1630834, was opened at 2007-01-08 14:21 Message generated for change (Comment added) made by anshnd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1630834&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Christian Queinnec (queinnec) Assigned to: Nobody/Anonymous (nobody) Summary: Accurately naming parameterized tests Initial Comment: Hi, Naming parameterized tests with numbers 1, 2, ..., N,makes difficult to retrieve the exact test that fails. For instance, for a compiler I wrote, I successively evaluate long series of files (all are evaluated with the same method) and prefer to see the filename rather than the number of the test. Here are the changes: @Parameter now returns a Collection of TestClassParameters: an interface that offers two methods: getParameters() to retrieve the array of values and getName() to name the particular test. It looks nice under Eclipse. Hope it may help. Thanks for your great job. ---------------------------------------------------------------------- Comment By: Anli Shundi (anshnd) Date: 2009-11-16 13:56 Message: Please vote at http://github.com/KentBeck/junit/issues/#issue/44 ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: dasblinkenlight (dasblinkenlight) Date: 2007-08-20 19:18 Message: Logged In: YES user_id=1827208 Originator: NO A related discussion at https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1742040&group_id=15278 discusses alternative ways of addressing the same problem. I think that the Parameterized.java patch breaks backward compatibility, because parameterized test suites with @Parameters methods returning collections of Object[] will no longer work (I did not try it out, so there is a possibility that I missed something when reading the code; I'm sorry if I did). At the very least, the patch should address this issue by falling back on the old implementation when the @Parameters method returns object arrays not wrapped in TestClassParameters implementations. However, I still think that a solution based on @TestName annotation would be cleaner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1630834&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 17:53:05
|
Feature Requests item #434863, was opened at 2001-06-20 14:12 Message generated for change (Comment added) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=434863&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Vladimir Ritz Bossicard (vbossica) Assigned to: Nobody/Anonymous (nobody) Summary: Plug-in modules Initial Comment: Don't know if this has 1 single chance to be considered but here's my proposition. Goal: design plug-in capability for TestResult listeners. A plug-in will receive the "addFailure", "addTests" evenements from the TestResult object and will deal with it (update an XML tree, write into a file, add statistics...) Advantage: - a better modularity - enable people to write their own listeners and plug them easily via property files - BaseTestRunner don't deal with the dispatch of failures and errors Implementation: - TestResult object doesn't store the errors and failures (the failure() method is used only _once_ and this behaviour can be replaced by the proposed plug-in mechanism) - Only the TestResultListeners store (if they need to) tests, errors and failures. That is what is already done with the Lists and Trees objects. - BaseTestRunner does not implement TestListener anymore but contains a list of TestResultListeners (display tree, list, user-defined via property files...) - Trees and Lists and ProgressBar are TestResultListeners When running a test: - a TestResult instance is created - TestResultListeners are added to the TestResult's listeners by the BaseTestRunner - the TestSuite is run normally ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:53 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Christopher Eppstein (chriseppstein) Date: 2001-10-26 20:56 Message: Logged In: YES user_id=307090 I think this is a fantastic idea. I find the test result reporting and feedback to be the biggest area of improvement for junit. Having this feature would round it out so that it is available and usable for numerous uses... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=434863&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-11-16 17:53:02
|
Feature Requests item #535058, was opened at 2002-03-26 02:28 Message generated for change (Comment added) made by dsaff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=535058&group_id=15278 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Greg Vaughn (gvaughn) Assigned to: Erich Gamma (egamma) Summary: TestDecorator for threadsafe Asserts Initial Comment: Erich, I spoke to you this evening at the Javaworld awards at the Thirsty Bear about this Test Decorator. Yes, if the launched threads never complete, then they could stick around. I will further investigate some options to handle this case, but in the meantime I hope this code will give us a starting point to consider. David DeLano has found this useful for Visual Age Micro Edition. I can be reached at gv...@de... for futher discussion. I am open to other names of this class. I'm not particularly fond of it now, but I haven't been able to think of anything better. -Greg Vaughn ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-16 12:53 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-03-06 13:57 Message: Logged In: NO This is really useful,and a better solution then i had. Is this going to be part of Junit 4.0? On a quick glanced I didnt see it mentioned. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-05-20 10:37 Message: Logged In: NO test ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=535058&group_id=15278 |
