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-05 02:20:24
|
Feature Requests item #1941834, was opened at 2008-04-14 08:22 Message generated for change (Comment added) made by sf-robot 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: Closed 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: SourceForge Robot (sf-robot) Date: 2009-12-05 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-20 16:29 Message: Please continue the conversation at github! Thanks. ---------------------------------------------------------------------- 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-12-05 02:20:20
|
Bugs item #2900304, was opened at 2009-11-19 07:49 Message generated for change (Comment added) made by sf-robot 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: Closed 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: SourceForge Robot (sf-robot) Date: 2009-12-05 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: Jason Ng Yong Liang (jasonngyl) Date: 2009-11-21 14:44 Message: Ok, logged at GitHub. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2009-11-19 14: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-12-03 02:20:20
|
Feature Requests item #2816904, was opened at 2009-07-05 14:36 Message generated for change (Comment added) made by sf-robot 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: Closed 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: SourceForge Robot (sf-robot) Date: 2009-12-03 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-18 20: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 19: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 19: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 17: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-12-01 02:20:39
|
Feature Requests item #434863, was opened at 2001-06-20 18:12 Message generated for change (Comment added) made by sf-robot 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: Closed 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: 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: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-27 00: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-12-01 02:20:37
|
Feature Requests item #416828, was opened at 2001-04-17 20:34 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=416828&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: John Stoneham (jstoneham) Assigned to: Nobody/Anonymous (nobody) Summary: Integrated timing callbacks Initial Comment: As a development aid where I work, I've written a custom Swing UI on top of the junit framework. One of its features is to report and manipulate the timing of tests. The easiest current way to do this is through a TestDecorator such as that included in <a href="http://www.clarkware.com/software/JUnitPerf.html" >JUnitPerf</a>. The problem here is that this approach can afford no finer granularity than finding time(setUp() + test() + tearDown()). The solution I found was to extend TestListener with a new callback, addTime(Test,long), similar to addFailure() and addError(), with the first argument being similar to the Test argument in all the other TestListener callbacks, and the long argument being the timing of -only- the actual test method of the last test run, in milliseconds, excluding the timing of setUp() and tearDown(). (This value is easily found by storing a System.currentTimeMillis() before and after the test, and registering the difference.) For the purposes of a wider-scale application, this could be extended to an addTime(Test,long,long,long), the three latter arguments being timing of setUp(), timing of test method, timing of tearDown(). The TestListener implementation interpreting the callbacks should retain full responsibility in interpreting the order of receipt of these callbacks; its own logic is determining the order in which test cases are run, and thus will be able to determine which callback applies to which test for reporting purposes. This does, however pose an issue for tests being run multiple times in their own threads - the developer must separate by test method and synchronize all the threads at the end of each method, or find another way to distinguish the callbacks (perhaps through the Test argument), as thread ending times will not be predictable. This modification may not be backwards compatible, unfortunately. It requires modifications to TestListener, requiring the addTime() function in all classes implementing TestListener. This would suggest a subclass of TestListener might work, but because we need to replace the call to runBare() from TestResult.run(TestCase), we would be calling a method on a TestListener that might or might not exist in particular instances, depending if they were from the subclassed version or not. Only a run-time type-id of the registered TestListener would solve this problem. The following is code for the one-argument version existing in my code (beware, it's written to JUnit 3.2): addition to TestListener.java: /** * The last-run test took testTime amount of time. */ public void addTime(Test test,long testTime); change in TestResult.java: protected void run(final TestCase test) { startTest(test); Protectable p= new Protectable() { public void protect() throws Throwable { // original statement. we need to add a timing call // here - replicate runBare() including timing call // REMOVED vvvvvvvvvv // test.runBare(); // REMOVED ^^^^^^^^^^ // ADDED vvvvvvvvvvvv test.setUp(); long startTime = System.currentTimeMillis(); try { test.runTest(); } finally { long endTime = System.currentTimeMillis(); addTime(test,endTime - startTime); test.tearDown(); } // ADDED ^^^^^^^^^^^^ } }; runProtected(test, p); endTest(test); } The reason this code needs to exist in TestResult is because TestResult is the class with which the TestListener is registered. There may be a better architectural solution to this via runProtected(), however. ---------------------------------------------------------------------- >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: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: 2001-08-07 22:28 Message: Logged In: NO This is a great idea. In addition, what if there was an assertMaxTimeSeconds(double) that could be called within a test method? When the method completes, if the time took more than the limit, this would be considered a duration failure. This would help identify situations where refactoring results in the same expected result, but whose run-time performance is unacceptable. ---------------------------------------------------------------------- Comment By: John Stoneham (jstoneham) Date: 2001-04-17 20:35 Message: Logged In: YES user_id=198358 [Apologies for the html and lack of indentation - I'm brand new to SourceForge and it shows. I'll know better next time.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=416828&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:36
|
Feature Requests item #535058, was opened at 2002-03-26 07:28 Message generated for change (Comment added) made by sf-robot 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: Closed 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: 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: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 18: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 14:37 Message: Logged In: NO test ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=535058&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:36
|
Feature Requests item #1077907, was opened at 2004-12-02 21:10 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1077907&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: Oliver Kamps (okamps) Assigned to: Nobody/Anonymous (nobody) Summary: assert methods testing result of compareTo Initial Comment: I have had the need to test the result of calling compareTo on several occasions. Therefore, I have a added a number of methods to Assert which assert that the result of calling compareTo is smaller than zero, 0, or greater than zero for the specified arguments. I have added corresponding tests to AssertTest. The contributions are marked by //contribution start and //contribution end in the attached files. Please let me know if you have any questions or comments. Thanks. ---------------------------------------------------------------------- >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:53 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Oliver Kamps (okamps) Date: 2006-07-04 13:50 Message: Logged In: YES user_id=133636 I could use assertEquals if I applied Math.signum() to the result of the compare()/compareTo() method call. However, this is far from readable and, what's worse, does not communicate intent. Thank you for your follow-up. ---------------------------------------------------------------------- Comment By: Matthias Schmidt (cmschmidt) Date: 2006-07-04 12:57 Message: Logged In: YES user_id=1523407 You can use assertEquals(int, int) for this purpose, can't you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1077907&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:36
|
Feature Requests item #1077910, was opened at 2004-12-02 21:14 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1077910&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: Oliver Kamps (okamps) Assigned to: Nobody/Anonymous (nobody) Summary: AssertTest: added tests for assertCompore methods Initial Comment: I just submitted an addition to the Assert class. This submission contains the corresponding test methods in AssertTest. ---------------------------------------------------------------------- >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:53 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=1077910&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:36
|
Feature Requests item #1187689, was opened at 2005-04-21 21:37 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1187689&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: Nobody/Anonymous (nobody) Assigned to: David Saff (dsaff) Summary: assertNotEquals/Less/GreaterThan functions Initial Comment: I'd really think it'd be useful to have a function that tests to make sure a retrieved value doesn't equal another. For example, if you look up an index while searching, and then are ready to pass it to the array for looking up. You could check to make sure the value is not greater than the index or less than 0. The notEquals functions would also be helpful for users that return certain values as integers (as I do sometimes). And the implementation would be...well, cake. ---------------------------------------------------------------------- >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:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: rei3ner (rei3ner) Date: 2006-06-04 21:30 Message: Logged In: YES user_id=1316370 i share this opinion. in fact i have written a class providing appropriate methods. if wanted i can donate my work with JUnit4 this collides with Assert-class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1187689&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:35
|
Feature Requests item #1114925, was opened at 2005-02-02 18:11 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1114925&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: james abley (taboozizi) Assigned to: Nobody/Anonymous (nobody) Summary: New TestListener2 interface for hierarchical reporting Initial Comment: If I go to the trouble of giving a TestSuite a name, it's probably because I'm interested in being notified when that suite starts and when it ends. This is a new interface that extends TestListener to provide these notification events, with accompanying changes to TestSuite, TestResult and new test cases to demonstrate the functionality. This has allowed me to write a simple Ant task (not included) which can report a hierarchy of test suites, similar to the Swing Test Runner and SWT Runner in Eclipse, and no doubt in other IDE's as well. ---------------------------------------------------------------------- >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:53 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: james abley (taboozizi) Date: 2005-02-06 15:10 Message: Logged In: YES user_id=846246 This patch file was created against the HEAD using Eclipse and then tested to ensure that it can be successfully applied. One item that I'd draw people's attention to is that I used a List interface and ArrayList implementation in the TestResult changes, which isn't homogenous with the existing Vector usage. I wasn't sure whether this code was still like that to maintain compatability with older JVM's? I use 1.4.2 at home and work, so supporting Java 1.1 or similar wasn't high up the feature list when I created this patch. ---------------------------------------------------------------------- Comment By: james abley (taboozizi) Date: 2005-02-05 11:21 Message: Logged In: YES user_id=846246 I found that the problem with the initial patch was caused by my use of Eclipse and the editor's code formatter. The resulting patch wouldn't go on, due to too many structural changes. I haven't been able to connect to cvs or browse the web ui to get a fresh copy of the HEAD - as soon as I do, I'll resubmit. James ---------------------------------------------------------------------- Comment By: james abley (taboozizi) Date: 2005-02-02 22:03 Message: Logged In: YES user_id=846246 Sorry, the initial attached patch doesn't work, at least when trying to apply it to a clean cvs checkout in eclipse. I'll resubmit. James ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1114925&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:35
|
Feature Requests item #1267495, was opened at 2005-08-23 22:01 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1267495&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: Neil Swingler (neil_swingler) Assigned to: David Saff (dsaff) Summary: Generic way to decorate a test case Initial Comment: This is in part inspired by Robert Watkins post on the junit yahoo group about junit 4: http://groups.yahoo.com/group/junit/message/13909 Many junit extensions come with their own subclass of TestCase (e.g. JMock) unfortunately this means they cannot be combined due to the single inheritence of classes. The solution to this is to use decorators but that means manually constructing test suites. I came up with a base class for decoratable test cases based on the 3.81 code base: http://cvs.sourceforge.net/viewcvs.py/jisolate/jisolate/src/net/sourceforge/jisolate/junit/DecorateableTestCase.java?view=markup The current architecture for junit4 would defeat this. The main reason for dropping the Test interface and decorator pattern is supposed to be to enable IDE runners to rerun a single test without worrying about decorators which may have been installed at the suite level. However, having a hook to install decorators at the individual test level would not complicate the runner. Examples of the sorts of decorators I would like to install include - Installing a custom classloader to allow sophisticated mocking or isolation of static variables - Waiting for all spawned threads to terminate before completing the test - Timing out a test (although this is already covered in JUnit 4) ---------------------------------------------------------------------- >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:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Chris Long (aclong) Date: 2006-05-18 15:25 Message: Logged In: YES user_id=649710 Another decorator I'd like to use is for tests that are allowed to fail a certain percentage of the time (for example, network messaging that has to have latency < x for at least y% of messages). It would be most flexible to be able to annotate individual test methods, but would probably be adequate for us to be able to set this at the class level. ---------------------------------------------------------------------- Comment By: Jogi (jgottschling) Date: 2005-10-07 10:43 Message: Logged In: YES user_id=1275777 It would also be nice to have a @Decorate Attribut wich can be use to decorate the complete class (the resulting TestSuite) or a single Test with one or more Decorators. But I think this would need a TestDecorator Interface or something like this. Perhaps a Convention like "must probide a public constructor which takes a Test as single argument" would do the Job. Or TestDecoratorFactory could be used. But something very simple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1267495&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:35
|
Feature Requests item #1219967, was opened at 2005-06-13 21:00 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1219967&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: Nobody/Anonymous (nobody) Assigned to: David Saff (dsaff) Summary: TestCase needs assertNotEquals() Initial Comment: How am I supposed to test for non-equality? - assertNotSame tests for object identity (that is, non-identity) - assertFalse(!o1.equals(o2)) is not the same, because is would not give any information about the assertion that failed ---------------------------------------------------------------------- >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: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=1219967&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:35
|
Feature Requests item #1312401, was opened at 2005-10-03 23:09 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1312401&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: Giovanni Pelosi (hute37) Assigned to: Nobody/Anonymous (nobody) Summary: Time (Iterated) Test Wrapper Initial Comment: I have written a JUnit extension to wrap a simple test case, used to run to test for a fixed number of iterations. * It prints total and average execution time. * It let to verify total and average time execution. I was inspired by RepeatedTest and JUnitPerf TimedTest extensions, but, for a better accurancy, test iteration is done with caching on reflection invoke. setUp and tearDown methods are called before and after iteration block (but this can be extended to conditionally do these calls in iteration block). A testSuite extension is provided to collect time statistics automatically (with a fixed numer of iterations) ---------------------------------------------------------------------- >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: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=1312401&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:34
|
Feature Requests item #1557017, was opened at 2006-09-12 10:26 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1557017&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: Matthias Schmidt (cmschmidt) Assigned to: Kent Beck (kbeck) Summary: performance optimization for Assert Initial Comment: I've made JUnit's central class Assert a tiny bit faster by doing two things: 1) Using StringBuilder instead of concatenating Strings for the error messages. StringBuilder is the thread unsafe brother of StringBuffer, introduced in Java 5. 2) Using the factory methods for numbers, e.g. "Double.valueOf(double)" instead of "new Double(double)". Quote from the javadoc: "If a new Double instance is not required, this method should generally be used in preference to the constructor Double(double), as this method is likely to yield significantly better space and time performance by caching frequently requested values." ---------------------------------------------------------------------- >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: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=1557017&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:34
|
Feature Requests item #1247104, was opened at 2005-07-28 20:50 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1247104&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: Elliotte Rusty Harold (elharo) Assigned to: Nobody/Anonymous (nobody) Summary: @Ignore by platform Initial Comment: I'm not fully up on annotations yet, so my apologies if this is just not possible, but it strikes me that it would be nice if @Ignore took a platform parameter of some kind. That is I;d like to say something like @Ignore(platform=macos) to skip running the test on the Mac. or perhaps it should be the reverse, and this should only run the test on the Mac. I frequently encounter two cases where this would be useful: 1. tests that expose platform bugs and thus fail on one platform but not others. 2. Tests that are specific to a platform. For instance. on Windows I might test that the File menu has an Exit menu item but I wouldn't make that test on a Mac. Perhaps this parameter (or do we need two?) could even be generic. i.e. it could be used on @Test, @Before, @After as well as @Ignore. But something like this would be very helpful. ---------------------------------------------------------------------- >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:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Elliotte Rusty Harold (elharo) Date: 2006-10-06 14:12 Message: Logged In: YES user_id=226817 I suspect the @Prerequisite annotation would satisfy this use case. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2006-09-30 17:39 Message: Logged In: YES user_id=325156 Interesting. Can you give an example where Antirequesite would be useful? It doesn't look like @Platform, as described here, would give you that functionality, either. ---------------------------------------------------------------------- Comment By: Elliotte Rusty Harold (elharo) Date: 2006-09-29 14:30 Message: Logged In: YES user_id=226817 More or less, though some of the use cases I have in mine are more of an Antirequisite than prerequisite. For instance, I often what to say run this test *unless* something is true, rather than run this test *only if* something is true. Of course you could reverse the logic (run this test if something is not true) but that's usually more opaque. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2006-09-29 13:56 Message: Logged In: YES user_id=325156 I agree with the previous comment. Elliotte, would 1447312 satisfy your needs? ---------------------------------------------------------------------- Comment By: Henk van Voorthuijsen (voorth) Date: 2006-04-26 09:54 Message: Logged In: YES user_id=261177 Interestingly, this could be handled as a special case of 1447312... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1247104&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:34
|
Feature Requests item #1434719, was opened at 2006-02-19 19:04 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1434719&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: Nobody/Anonymous (nobody) Assigned to: David Saff (dsaff) Summary: Support test categorization Initial Comment: With the filtering mechanism provided by junit 4.0, test categorization would be a very simple addition. Prefereably, "category" (or "categories") would be a parameter of the @Test annotation, but there could also be a separate @Category 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: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=1434719&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:34
|
Feature Requests item #1552931, was opened at 2006-09-05 19:26 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1552931&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: John Maloney (jmmaloney3) Assigned to: Nobody/Anonymous (nobody) Summary: Better support for extensions to ClassRequest Initial Comment: Give the getRunnerClass(Class) method in org.junit.internal.requests.ClassRequest protected visibility rather than package private visibility. This would make it easier to extend ClassRequest. One reason to extend ClassRequest is to have it return an extension to OldTestClassRunner that supports filtering. This particular use case could be addressed by modifying the implementation of OldTestCaseRunner to support filtering. ---------------------------------------------------------------------- >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: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=1552931&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:34
|
Feature Requests item #1526798, was opened at 2006-07-22 01:10 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1526798&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: Nobody/Anonymous (nobody) Assigned to: David Saff (dsaff) Summary: JUnit .jar should work in jre\lib\ext Initial Comment: It would be very nice if the junit-4.1.jar could just be dropped into <java dir>\jre\lib\ext without having to always declare a CLASSPATH. The following two changes have been verified to work on Windows 2000: 1. On line 70 of org\junit\runner\JUnitCore.java, replace the text "Class.forName(each)" with the text "Class.forName(each, true, ClassLoader.getSystemClassLoader())". 2. On line 209 of junit\runner\BaseTestRunner.java, replace the text "Class.forName(suiteClassName)" with the text "Class.forName(suiteClassName, true, ClassLoader.getSystemClassLoader())". With these two changes made, the standard suite of tests (the "AllTests" suite) passes (on a Windows 2000 system using JDK 1.5.0_07) with "junit-4.1.jar" dropped into the "...\jre\lib\ext" directory and with the CLASSPATH variable left blank. If there is no subtle reason why these changes shouldn't be made (I am a complete JUnit greenhorn and may not know of some well-known problem), then these changes could make the installation of JUnit much easier for us command-line users. Thank you, Eric R. Salberta eri...@L-... ---------------------------------------------------------------------- >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:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2006-09-29 13:31 Message: Logged In: YES user_id=325156 Actually, I'm pretty sure that simply making those changes would break the Eclipse JUnit Plug-in test loader, among other possible things. I'll modify this feature request to include: 1) A command-line switch that enables the system class loader 2) Tests for both behaviors. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2006-09-29 13:27 Message: Logged In: YES user_id=325156 I'm referring to the mailing list for comment--I think some people use custom classloaders, and this might screw them up (I haven't thought deeply enough to know exactly how). I'll come back to this in a week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1526798&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:34
|
Feature Requests item #1580815, was opened at 2006-10-19 20:58 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1580815&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: Bill Wallace (wayfarer3130) Assigned to: Nobody/Anonymous (nobody) Summary: @BeforeClass and @Test combined Initial Comment: It would be nice to have tests that are also the "before" item. That would disable any tests in the before class sub-classes if the primary test fails. This would be used for things like a login test - the login itself is a test that needs to be reported, but it is also a pre-requisite for other tests. Similarly, the logout is a post-condition test that must succeed on its own (and needs to be included in the number of tests run), but also serves as a @AfterClass item. This latter test isn't as important because the point of having a pre-condition test run before many other tests is at least partly to not have to report N tests failed when really it is only the @BeforeClass test that failed. ---------------------------------------------------------------------- >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: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=1580815&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:34
|
Feature Requests item #1535172, was opened at 2006-08-05 21:25 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1535172&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: Pierre (pierre42) Assigned to: David Saff (dsaff) Summary: Separate distributions Initial Comment: Hi, I think it would be great if you could make 2 separate release for junit : one only binary, and the other with the source files only. ---------------------------------------------------------------------- >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:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: Matthias Schmidt (cmschmidt) Date: 2006-08-31 08:05 Message: Logged In: YES user_id=1523407 I like that suggestion, I agree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1535172&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:34
|
Feature Requests item #1435782, was opened at 2006-02-21 10:05 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1435782&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: J. David Beutel (david_beutel) Assigned to: Nobody/Anonymous (nobody) Summary: dynamically check for arrays and Collections Initial Comment: With JDK 1.5 generics and auto-boxing, I'll use Collections more often. So, I think it would be useful to do array-like assertEquals() on ordered Collections. Building on my previous patches, I changed assertEquals() to check for arrays dynamically, and handle ordered Collections like it does arrays. Sets (but not SortedSets) are handled as before. I just tried this, but I haven't used it yet, so it's only experimental. It could be simplified if the output format were changed. versions: junit 4.0, JDK 1.5.0_06, ant 1.6.5, Fedora Core 3. ---------------------------------------------------------------------- >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:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: J. David Beutel (david_beutel) Date: 2006-02-22 09:16 Message: Logged In: YES user_id=484527 Taking the next step in this experiment, I changed assertEquals() to check for Float and Double dynamically. Now the delta works on Float and Double array elements, and there are no more primitive parameters for expected and actual. To avoid ambiguity, I had to rename the assertEquals() taking a delta (to assertEqualsDelta()). I also added handling for arrays of primitives. This is just experimental, and needs some review, but I think it's an interesting idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1435782&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:33
|
Feature Requests item #1569263, was opened at 2006-10-02 12:50 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1569263&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: Jochen Hiller (jhiller) Assigned to: Nobody/Anonymous (nobody) Summary: Description does not allow access to metadata via reflection Initial Comment: During implementation of filter and sorter (based on annotations), I recognized, that Description (part of the callbach for filter/sorter) does NOT allow to access the tested method via reflection. This makes it nearly impossible to lookup own annotations for a given test method. A hack is to parse string presentation of description, whichs allow to extract test class and test method, but this is a very ugly solution. Please, rethink design of Description, whether there could be access to test method including reflection access. At minimum when aDescription.isTest(), probably not for suites. See also: - https://sourceforge.net/tracker/?func=detail&aid=1447312&group_id=15278&atid=365278 as first feature request - http://www.junitext.org for samples. ---------------------------------------------------------------------- >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: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=1569263&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:33
|
Feature Requests item #1472701, was opened at 2006-04-19 01:49 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1472701&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: tieTYT (tietyt) Assigned to: David Saff (dsaff) Summary: Make all JUnit 4TestCases backwards compatible with JUnit3 Initial Comment: There are some test cases in the JUnit4 branch that do not include the backwards compatibility code. In other words they're missing this: static public junit.framework.Test suite() { return new JUnit4TestAdapter(AssertionTest.class); } org.junit.tests.ValidationTest is an example of this. Thanks, Dan ---------------------------------------------------------------------- >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: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=1472701&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:33
|
Feature Requests item #1542845, was opened at 2006-08-18 20:13 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1542845&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: TOF (dash-13) Assigned to: David Saff (dsaff) Summary: Fix excecptions breaking the listners Initial Comment: As described in feature request 1539242, exceptions that throw themselfes on any of their methods .getMessage(), and .printStackTrace() will break the operation of many listners, e. g. the org.junit.internal.runners.TextListener. When trying to report the failures, these Listners usually pass the resulting exception up into RunNotifier.SafeNotifier, resulting where this is interpreted as a failure of the listner, not a problem of the application under test. As a result, these listners get removed, eventually leaving the notifier with nothing to report to, and effectivly muting the output of junit, depriving the user of any hint to the cause. The fix provided adresses this in two ways: 1.) The methods of Failure.class are enhanced, to protect the framework against rogue exceptions. This will help for listners, that use the methods Failure.getMessage() and Failure.getTrace(). Others extracting the Exception and treating it themselfes are still on their own. 2.) RunNotifier.SafeNotifier is changed to throw a RuntimeException the momenent the last surviving Listner is removed, thus giving the programer a starting point to untangle the mess. The Fix also adds a unit test class for Failure.class, and a test in TestListnerTest for 2.) Regards Thomas ---------------------------------------------------------------------- >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:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2006-10-17 15:59 Message: Logged In: YES user_id=325156 These seem reasonable. I'll look further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1542845&group_id=15278 |
|
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:33
|
Feature Requests item #1539242, was opened at 2006-08-12 16:41 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1539242&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: TOF (dash-13) Assigned to: Nobody/Anonymous (nobody) Summary: Weir exceptions are break error handling/report of Junit 4.1 Initial Comment: Because of a dumb fault of mine, I had a tough time figuring out what went wrong with junit... My fault: the getMessage() method of an Exception class I wrote caused a NullPointerException. This caused some pretty odd behavior, denying me any hint, what might have went wrong: Part A: Using the plain command line with the build in TextListner, I got: JUnit version 4.1 EE.E.........E...E.E................. Time: 441,976 There were 6 failures: 1) myTest[0](my.Package.MyTest) ... and exitus. This, for once, is caused by org.junit.runner.notification.Failure.getTrace(): public String getTrace() { StringWriter stringWriter= new StringWriter(); PrintWriter writer= new PrintWriter(stringWriter); getException().printStackTrace(writer); StringBuffer buffer= stringWriter.getBuffer(); return buffer.toString(); } where printStackTrace() delegates implicitly to getMessage(). The resulting NPE is passed up to JUnitCore.run() and never ever intercepted. How I found this is Part B: In absence of a yet stable TestListner in my favorite IDE, and not yet aware of the NPE in getMessage(), I decided to brew my own - only to discover, that it quits reporting the very moment, it should have shown the exception! This is due to the following piece of code in RunNotifier: Line 34: private abstract class SafeNotifier { void run() { for (Iterator<RunListener> all= fListeners.iterator(); all.hasNext();) { try { notifyListener(all.next()); } catch (Exception e) { all.remove(); // Remove the offending listener first to avoid an infinite loop fireTestFailure(new Failure(Description.TEST_MECHANISM, e)); } } } This could be called 'according to spec', because elsewhere the java doc tells, that listners throwing are removed, but using the cow bells example, this means silencing the cow bell, when it should have been toling like hell. If still interested, I see several possible solutions towards a more helpfull response to users: a.) Exceptions stuffed into the Failure class shouldn't be accessed directly. Failure could be used to wrap the acces, which lends an opportunity to safeguard against misbehaving exceptions as well as reporting details regarding the nature of the problem. b.) It might be OK to remove a corrupted TestListner to prevent problems, but think it is unwise, if it's not the TestListner, but rather the data it got. I'm also not sure, if I'd like to have news about the failing Listner disseminated into all other listners that happen to be registered. Couldn't we use the parent class RunListner as sort of proxy, say, implementing a 'protectedTestFailure()' which delegates to testFailure, retries with a modified Exception in case of problems, and finally dumps to System.err, before giving up? c.) As a last resort and precaution: JUnitCore should intercept and dump any exceptions that make it through. Well, obviously, I should have tested my exception class before starting to throw it around ;-) Best Regards, T. S. ---------------------------------------------------------------------- >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:52 Message: This tracker is being shut down. Please move this item to http://github.com/KentBeck/junit/issues ---------------------------------------------------------------------- Comment By: TOF (dash-13) Date: 2006-09-30 19:30 Message: Logged In: YES user_id=1557775 I allready moved on: Patch 1542845 offers a remedy. As I found out during the implementation, I was wrong on the assumption, that the failure to report the exception was on account of the framework not passing up uncaught throwables. In fact, it does. But unfortunately, the build in TextListner gets caught by the same snatch that silenced my custom listner: it simply gets removed when trying to report the poisoned exception, leaving the framework with no listner to report to! As in Patch 1542845 explained, this is fixed by: - treating poisoned exceptions as sugested in a.) - as a precaution, throwing a runtime exception, when the last listner is removed, which addreses b. & c.) in a much simpler fashion than originally expected. The fix contains a testcase too. So if you agree to the patch, this case might be closed. Hope this helps, T. S. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2006-09-29 13:23 Message: Logged In: YES user_id=325156 I totally agree with items a and c, and would like to further discuss item b. To help with housekeeping, can you a new issue for each item (with a reference to this one)? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1539242&group_id=15278 |
