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:32
|
Feature Requests item #1565177, was opened at 2006-09-25 15:50 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1565177&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: Bruce Dunwiddie (shriop) Assigned to: Nobody/Anonymous (nobody) Summary: Be able to optionally specify expected exception message. Initial Comment: NUnit allows you to optionally specify an expected exception message on an expected exception instead of just relying on the exception type. ---------------------------------------------------------------------- >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: Alex (toalexsmail) Date: 2009-05-04 13:52 Message: "timhobson" does your solution is extensible to check caused exception? Type, error message and recursively it's cause. It will be very nice. ---------------------------------------------------------------------- Comment By: Alex (toalexsmail) Date: 2009-05-04 13:50 Message: You're not the only one. I wrote my post about a year ago and I still wait for this feature (while I don't consider it critical). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-02-13 15:00 Message: "nobody" says thank you for your interest! It feel strange to me if i were the only one interested in this feature. Do you plan to contribute to a next version of junit? Franois Wauquier ---------------------------------------------------------------------- Comment By: Tim Hobson (timhobson) Date: 2008-12-23 21:43 Message: I recently implemented this functionality for my own purposes. Is there interested in me publishing the implementation for wider consumption? I followed the pattern submitted by "nobody": @Test (expected=SomeException.class, expectedMessage="Some Message") public void method(){ method(); } I'm now working to find a way to make this even more extensible, where it can assert on "error codes" or other attributes of the exception which are specific to a type of Exception class. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-12-01 10:02 Message: Junit3 public void testMethod(){ try{ method(); fail(); }catch(SomeException e){ assertequals("Some Message",e.getMessage()); } } Wanted Feature in Junit4 @Test (expected=SomeException.class, expectedMessage="Some Message") public void method(){ method(); } It would be possible to specify the class, the message, both, or none of them. please. ---------------------------------------------------------------------- Comment By: Alex (toalexsmail) Date: 2008-03-12 21:20 Message: Logged In: YES user_id=2034775 Originator: NO It will be also very nice to specify expected cause exception. It is useful in the case of InvocationTargetException and EJBException. It should be also nice to be able to note what "getCause()" method to call. For example, in EJBException getCausedByException() should be callled. In both JBoss and Glassfish implementation getCause() always returns null. It can be also nice to point on cause of the cause and so on. It is simply to implement by recursion. ---------------------------------------------------------------------- Comment By: Bruce Dunwiddie (shriop) Date: 2006-12-12 16:24 Message: Logged In: YES user_id=479533 Originator: YES Here's what my C# test case is using NUnit: [Test()] [ExpectedException(typeof(ArgumentNullException), "Data can not be null.\r\nParameter name: data")] public void Test77() { CsvReader.Parse(null); } Evidently, they don't actually have an example of using this constructor overload in their online documentation, at least not that I can easily find. Here's my java test case done the best way I can come up with to accomplish the same thing: @Test public void test77() { try { CsvReader.parse(null); } catch (Exception ex) { assertException(new IllegalArgumentException( "Parameter data can not be null."), ex); } } ---------------------------------------------------------------------- Comment By: Santiago L. Valdarrama (svpino) Date: 2006-12-12 15:41 Message: Logged In: YES user_id=818352 Originator: NO Could you provide a NUnit sample to see that behaviour in action? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1565177&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:31
|
Feature Requests item #1580810, was opened at 2006-10-19 20:54 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1580810&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: Add ignore override to runner Initial Comment: If there are a number of tests that fail, and some change has been made that might improve some of the failures, or just after some length of time has passed without working on the ignored items, it would be nice to have a way to run everything, including the "ignored" tests. This is particularly important if you work in an environment where the unit tests are all required to pass, except those explicitly marked ignore - there needs to be some way to run that as a single-time test, or to run all ignores anyways. ---------------------------------------------------------------------- >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=1580810&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:31
|
Feature Requests item #1569265, was opened at 2006-10-02 12:57 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1569265&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: Filter / Sorter do NOT have access to current test object Initial Comment: When calling a filter or sorter, there is no access to the current test object. This makes it impossible for own implementations, to call a method on the current test object. E.g. an annotation @Prerequisite(requires="isDBavailable") would like to call an instance method of the current test object. An workaround has been, to implement a custom runner, which has to be attached via @RunWith(AnnotationRunner.class), which checks for own annotations, and then call specific implementation based on the annotation. Could be a template for a general AnnotationSupportingRunner, where own annotations could be registered. Or, extend the filter/sorter interfaces to allow access to current test object. ---------------------------------------------------------------------- >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=1569265&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:31
|
Feature Requests item #1565184, was opened at 2006-09-25 15:57 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1565184&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: Bruce Dunwiddie (shriop) Assigned to: Nobody/Anonymous (nobody) Summary: Allow implicit numeric casts on assertEquals Initial Comment: Currently, when checking for an expected value of a long, you must put the L after the expected value to get the assertEquals to pass. An implicit numeric conversion or wider comparison here would be nice. For example, Assert.assertEquals(0L, reader.getCurrentRecord()); would be nicer as, Assert.assertEquals(0, reader.getCurrentRecord()); ---------------------------------------------------------------------- >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: Santiago L. Valdarrama (svpino) Date: 2006-12-12 15:53 Message: Logged In: YES user_id=818352 Originator: NO The other solution is to change the signature of the assertEquals methods to something like this: static public <T> void assertEquals(String message, T expected, T actual) and update the other related methods (i.e. failNotEquals). This is really a very easy work to do. ---------------------------------------------------------------------- Comment By: Santiago L. Valdarrama (svpino) Date: 2006-12-12 15:40 Message: Logged In: YES user_id=818352 Originator: NO This behaviour is caused by the automatic boxing/autoboxing feature of jdk 1.5. If you look carefully into the details of the Assert class, you will realize that there is only one assertEquals method that receive two objects for comparison purposes (version 3.8 implements one assertEquals for each data type). This behaviour is ok for me, however, the solution will be as easy as implementing some stubs methods for each kind of type (like previous junit versions). These methods will delegate the assertion implementation to the already existing assertEquals method. Something like this: static public void assertEquals(String message, long expected, long actual) { assertEquals(message, new Long(expected), new Long(actual)); } static public void assertEquals(String message, short expected, short actual) { assertEquals(message, new Short(expected), new Short(actual)); } ... and so on... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1565184&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:30
|
Feature Requests item #1623162, was opened at 2006-12-27 21: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=1623162&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: internal Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: David Saff (dsaff) Assigned to: David Saff (dsaff) Summary: Duplicate code in TCMRunner and ERRunner Initial Comment: TestClassMethodsRunner and ErrorReportingRunner have almost the same code at one point: notifier.fireTestStarted(description); notifier.fireTestFailure(new Failure(description, cause)); notifier.fireTestFinished(description); This should live in an appropriate home, referenced from both places. ---------------------------------------------------------------------- >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=1623162&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:30
|
Feature Requests item #1597307, was opened at 2006-11-15 21:51 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1597307&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: Mark Mosher (mmosher) Assigned to: Nobody/Anonymous (nobody) Summary: WaitingAsserter Initial Comment: A feature for waiting for a condition to become true, that is, not failing if the condition is not immediately true. This is useful in multi-threaded and/or client/server architectures, particularly GUI or event-based applications. Take the case of an application setting a value on a server (or mock server object), where that call returns immediately, and at some point in time the server fires an event on some thread, the client app gets that event and updates a object's state based on that event. We want to verify the round trip, specifically that the object state was updated based on our call to the server, but this won't happen immediately. We should be willing to wait for some period of time for the condition. What I have created is the notion of a waiting asserter, which waits up to 10 seconds (configurable) for an assert condition to become true, e.g. such as assertTrue or assertEquals. This works for me when I do something that eventually fires an event and I want to verify that the right event fired (possibly on a different thread) or the correct callback method eventually was invoked with the correct parameter as a result. And other things like Did a control change state as a result of another control being selected? WaitingAsserter.java is attached. I have a corresponding WaitingAsserterTest, but it appears that I can only attach one file here. Example usage (to assert that clicking on the doClickButton results in setEnabledButton being enabled): final JButton setEnabledButton = new JButton(); setEnabledButton.setEnabled(false); final WaitingAsserter waitingAsserter = new WaitingAsserter(setEnabledButton.isEnabled()); waitingAsserter.assertFalse(); setEnabledButton.addPropertyChangeListener(new java.beans.PropertyChangeListener() { public void propertyChange(java.beans.PropertyChangeEvent evt) { waitingAsserter.setValue(evt.getNewValue()); } }); final JButton doClickButton = new JButton(); doClickButton.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent ae) { setEnabledButton.setEnabled(true); } }); new Thread(new Runnable() { public void run() { try {Thread.sleep(500);} catch (InterruptedException ie) {} java.awt.EventQueue.invokeLater(new Runnable() { public void run() { doClickButton.doClick(); } }); } }).start(); waitingAsserter.assertTrue(); Best regards, Mark ----- Mark Mosher Manager, Product Applications EMRT Office: (585) 219-5900 x404 Mobile: (585) 455-0572 mm...@em... www.emrt.com ---------------------------------------------------------------------- >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=1597307&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:30
|
Feature Requests item #1619676, was opened at 2006-12-20 19: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=1619676&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: Charly51Etc (eduardkarelfrz) Assigned to: Nobody/Anonymous (nobody) Summary: Comparison Failure for short strings Initial Comment: The string compression processing seems overkill for short strings, making them actually longer in the output. A class constant: /** *Dont bother with Strings shorter that this. */ private static final int DONT_BOTHER_LENGTH = 6 ; and a test if(source.length() <= DONT_BOTHER_LENGTH) return source; at the start of private String compactString(String source) should basically do the trick... ---------------------------------------------------------------------- >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=1619676&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:30
|
Feature Requests item #1581916, was opened at 2006-10-21 18:30 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1581916&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: Using APT to find JUnit API usage errors at build time Initial Comment: The following patch intoduces an APT processor into junit.jar, that is able to uncover a number of commonly made mistakes when writing 4.1 test cases. Among the things tested: - that methods / classes are public / static / parameterless / void etc as required. - that the proper constructors exist. - that the value of RunWith matches the other annotations present. and more. Usage is simple, e.g.: - you might use the apt commandline (plain or within ant) - you migth use ant 1.7-alpha (which supports apt) - in any ant java task you might specify executable="$(JDK_HOME}/bin/apt.exe" - or you might use eclipse 3.2. In any case, you just need to place the junit.jar into the factory path (look up suns documentation apt) The patch is complete with testcases, but also uncovers some things, that I like to discuss separately, time permitting. I'm also providing a readily built junit.jar for those not having the time or means to apply the patch and build on their own. If you are interested to introduce this into the distribution, I would volunteer to fix any outstanding issues with thie patch. 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1581916&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:29
|
Feature Requests item #1607483, was opened at 2006-12-02 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=1607483&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: Nat Pryce (npryce) Assigned to: Nobody/Anonymous (nobody) Summary: Make it easier to extend the existing Runners Initial Comment: I just added a JUnit 4 integration package to jMock 2. I needed to extend or plug into an existing Runner class to change the way it runs tests so that it automatically checked that all the test's expectations on its mock objects were satisfied before tearing down the fixture. To do this I had to subclass the Runner classes in JUnit's internal packages which I'm a bit uncomfortable about. I'd like the existing Runners be extensible or have known plug-in points to change the way that they run tests. ---------------------------------------------------------------------- >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=1607483&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:29
|
Feature Requests item #1625786, was opened at 2007-01-01 19:08 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1625786&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: Russ Jackson (arjackson) Assigned to: Nobody/Anonymous (nobody) Summary: Please add @Testable annotation Initial Comment: It would be great if you could add a @Testable annotation to the JUnit 4 framework so that users could annotate their source methods that require unit testing and tools could use this to generate assocated JUnit tests. Here is the requested annotation: import java.lang.annotation.*; @Retention(value = RetentionPolicy.SOURCE) @Target( { ElementType.CONSTRUCTOR, ElementType.METHOD } ) public @interface Testable { String value() default ""; } // Testable annotation type I recently added a plugin to IntelliJ IDEA that generates JUnit 4 tests. As part of that the plugin creates this annotation in the users source, the users annotate their testable methods and then the plugin generates the test classes/methods for these annotated methods. It would be nice if this annotation was available in the JUnit 4 framework. Thanks. Russ ---------------------------------------------------------------------- >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: Russ Jackson (arjackson) Date: 2007-01-01 19:27 Message: Logged In: YES user_id=1680949 Originator: YES Forgot to mention - the value() annotation method, in the case of the IDEA plugin, is used to name the test method. For example, the user can annotate their method with: @Testable("testLongAddition") and the plugin with generate a @Test annotated method with that name (otherwise, the annotated method name is simply prefixed with 'test'). The value() method depends on that being the only annotation method. Perhaps a more extensible solution would be to name the annotation method something like 'testName()'. The usage in this case would be: @Testable(testName="testLongAddition") You may also want to consider adding other annotation methods to testable to specify things like test paramters or anything else you think a tool developer would find helpful when generating JUnit tests from annotated source code. Thanks again. Russ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1625786&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:29
|
Feature Requests item #1627783, was opened at 2007-01-04 12: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=1627783&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: Martin Aeschlimann (aeschli15) Assigned to: Nobody/Anonymous (nobody) Summary: Support single method running for legacy tests Initial Comment: 4.2 Request.method(Class<?> clazz, String methodName) creates a request to run a single method. However, this only works for JUnit 4 runners, but not for JUnit 3 (OldTestClassRunner isn't filteable). In Eclipse we allowed single running of JUnit 3 tests by implementing this on top of the JUnit 3 runner. In JUnit 4 test creation is deeper inside the JUnit code so we can't offer this anymore for users running legacy tests with the JUnit 4 runner. ---------------------------------------------------------------------- >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: Markus Keller (make) Date: 2009-04-01 16:10 Message: This is still an issue that affects users who try to gradually convert their existing test suites to JUnit 4. ---------------------------------------------------------------------- Comment By: Martin Aeschlimann (aeschli15) Date: 2007-01-04 12:28 Message: Logged In: YES user_id=1591795 Originator: YES See https://bugs.eclipse.org/bugs/show_bug.cgi?id=169222 as the corresponding bug report in Eclipse. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1627783&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:29
|
Feature Requests item #1623185, was opened at 2006-12-27 22:21 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1623185&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: internal Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: David Saff (dsaff) Assigned to: Nobody/Anonymous (nobody) Summary: TestMethodRunner should take a TestMethod Initial Comment: TestMethodRunner currently takes as constructor arguments (Object test, Method method, RunNotifier notifier, Description description) Three of these arguments are bundled in the type TestMethod (if other coming commits are permanent). It would be better to use the new type, but extensions pointing at the internal packages should be warned if the constructor is going to change. ---------------------------------------------------------------------- >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=1623185&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:29
|
Feature Requests item #1626414, was opened at 2007-01-02 19:48 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1626414&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: Russ Jackson (arjackson) Assigned to: Nobody/Anonymous (nobody) Summary: Parameterize Test Methods Initial Comment: I see that the JUnit 4 @Parameters annotation works in conjunction with a parameterized test class constructor via an intermediary data method and test class members. Would it be possible to have it annotate (and parameterize) the test method instead? I believe the correlation between the test data and the test method would be much tighter, it would provide greater flexibility, and data could be injected into individual methods rather than the test class as a whole (which would allow for multiple, non-conflicting @Parameters annotations per test class). Here is a partial declaration of a revised Parameters annotation: @Interface Parameters { public Object[][] data(); } And here would be some examples of usage (please notice that the result param is the first param, rather than the last, to follow the structure of a varargs method declaration): @Test @Parameters(data = new Object[][] { {14, 1, 2, 3, 4, 4}, {0, 100, -100} } ) public void testIntegerAddition(int result, int... addends) { AssertEquals(result, MyMath.add(addends)); ... or @Test @Parameters(data = new Object[][] { {8, 64}, {ImaginaryNumberException, -64} } ) public void testSquareRoot(Object result, int value) { if (result instanceof ImaginaryNumberException) { try { MyMath.squareRoot(value); fail("Expected ImaginaryNumberException"); } catch(ImaginaryNumberException ine){ // OK - as expected } } else { AssertEquals((Integer)result, MyMath.squareRoot(value)); } Or, you could simply hang the test data on the @Test annotation, as so: @Interface Test { public Object[][] testData(); } And the usage would be: @Test(testData = new Object[][] { {8, 64}, {ImaginaryNumberException, -64} } ) public void testSquareRoot(Object result, int value) { ... Thanks. Russ ---------------------------------------------------------------------- >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: Alex (toalexsmail) Date: 2008-03-13 13:27 Message: Logged In: YES user_id=2034775 Originator: NO Hi Jonhnny ! I have looked on your sample, its look great. I will look on implementation details later. I have small question. Are you using @ParametersSource with method name that returns parameters for backward compatibility only? It would be nice that you could actually write parameters in annotation itself. But it can break backward compatibility. ---------------------------------------------------------------------- Comment By: Jonhnny Weslley (jweslley) Date: 2008-03-13 12:42 Message: Logged In: YES user_id=1627927 Originator: NO Hi Alex, I have an implementation in this feature request: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1674180&group_id=15278 However it was implemented junit-4.3.1. I can to update (if necessary) and post it here. What do you think about this? ---------------------------------------------------------------------- Comment By: Alex (toalexsmail) Date: 2008-03-12 21:24 Message: Logged In: YES user_id=2034775 Originator: NO I think it is great idea. I have currently no time, but I will look forward to implement this. ---------------------------------------------------------------------- Comment By: Jonhnny Weslley (jweslley) Date: 2007-02-28 17:04 Message: Logged In: YES user_id=1627927 Originator: NO Only primitive types, String, Class, annoatation, enumeration are permitted or 1-dimensional arrays. ---------------------------------------------------------------------- Comment By: Russ Jackson (arjackson) Date: 2007-01-02 20:16 Message: Logged In: YES user_id=1680949 Originator: YES Please revise the example @Test annotation as so: public @Interface Test { public Object[][] testData() default null; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1626414&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:29
|
Feature Requests item #1630834, was opened at 2007-01-08 19:21 Message generated for change (Comment added) made by sf-robot 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: Closed 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: 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: Anli Shundi (anshnd) Date: 2009-11-16 18:56 Message: Please vote at http://github.com/KentBeck/junit/issues/#issue/44 ---------------------------------------------------------------------- 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: dasblinkenlight (dasblinkenlight) Date: 2007-08-20 23: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-12-01 02:20:29
|
Feature Requests item #1648138, was opened at 2007-01-30 19:00 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1648138&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: Nobody/Anonymous (nobody) Summary: Expose TextListener as API Initial Comment: The TextListener used by default by JUnitCore provides an important and public functionality. Custom extensions should be able to use the TextListener in custom ways, while being able to track any future changes to the output format. (Submitted by dsaff, who's login appears to have been forgotten) ---------------------------------------------------------------------- >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: Alex (toalexsmail) Date: 2008-03-12 21:31 Message: Logged In: YES user_id=2034775 Originator: NO I have related suggestion. Currently TextListener on every event simply writes to standard output (or to PrintWriter). If junits or application aslo writes its logs to standard output then this output is mixed. For example, failures will be written inside the logs of the application and not in the end. Moreover, if there is some activity in @AfterClass that also prints to the standard output than this will be written down AFTER summary of the Junit. I have partial solution to this situation. TextListener (or a new class, say ConsoleListener) should create new PrintWriter(new StringWriter()) and collect the result their. On testRunFinished() it should flush the information from StringWriter to the PrintStream that received in the constructor (String.out for example). This solution doesn't solve situation when there is some writing to the standard output in @AfterClass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1648138&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:28
|
Feature Requests item #1653307, was opened at 2007-02-06 13:56 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1653307&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: Mike Aski (mike-aski) Assigned to: Matthias Schmidt (cmschmidt) Summary: Add version information to jar's manifest Initial Comment: In order to be manageable by Ant's jarlib-* tasks, JUnit's jar should include version informations. More details @ http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html ---------------------------------------------------------------------- >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: Mike Aski (mike-aski) Date: 2007-03-26 07:41 Message: Logged In: YES user_id=1712053 Originator: YES Perfect. Thanks a lot. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2007-03-24 02:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Matthias Schmidt (cmschmidt) Date: 2007-03-09 08:36 Message: Logged In: YES user_id=1523407 Originator: NO I updated the build.xml to create a manifest.mf containing the following: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.5 Created-By: 1.6.0-b105 (Sun Microsystems Inc.) Built-By: maschm Extension-Name: org.junit Specification-Title: JUnit Specification-Version: 4.3 Implementation-Version: 4.3 Is that okay for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1653307&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:28
|
Feature Requests item #1647993, was opened at 2007-01-30 15: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=1647993&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: G. Cooper (inanutshell) Assigned to: Nobody/Anonymous (nobody) Summary: @RunWith(LightweightParameters) Initial Comment: The intended use of Parameterized unit tests is for large amounts of data. With this in mind the most time-efficient convention to refer to an individual parameter is by index, i.e. "myTest[3912]". In cases where the data is a much smaller set and the user is willing to take a small performance hit, it would be nice to be able to refer to/see the parameters by a name, i.e. "myTest['testTwoPlusTwo']", "myTest['searchWithLastNameOnly']", etc. As was discussed on the JUnit mailing list ("Which parameter in my list failed?", 2007-01-29), something like a "@RunWith(LightweightParameters)" or "@RunWith(NamedParameters)", which would "look for a getTestName() method on the test object in order to create a test name" may be a good solution. ---------------------------------------------------------------------- >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: 2007-07-27 15:50 Message: Logged In: YES user_id=325156 Originator: NO Tibor, We could potentially build a method-renaming facility into the runners that ship with JUnit, but we would still have no control over third-party runners. If you have a particular use case in mind, consider opening another feature request. Thanks, David Saff ---------------------------------------------------------------------- Comment By: Tibor (bekesit) Date: 2007-07-26 22:08 Message: Logged In: YES user_id=1359662 Originator: NO Hi, This would be a great feature to be able to override the description of a test that should be used/displayed by all the runners. I would highly appreciate if this description could be set programatically to any string not only for parameterized tests, but for any kind of tests. Best regards, Tibor ---------------------------------------------------------------------- Comment By: Havard Rast Blok (havardrb2) Date: 2007-03-12 09:28 Message: Logged In: YES user_id=779926 Originator: NO I would also very much prefer such an option. As an alternative, maybe the existing Parameterized runner could have an option to include the parameters in its description. Example: "testAdd[0]: 1, 2, 3" "testAdd[1]: 2, 2, 4" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1647993&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:28
|
Feature Requests item #1655442, was opened at 2007-02-08 18: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=1655442&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: gz9nmp (gz9nmp) Assigned to: Nobody/Anonymous (nobody) Summary: Add Listeners by Annotation Initial Comment: Similiar to the @RunWith, there should be a means to add Listeners without having to work directly with the JUnitCore.addListener(RunListener) method. ---------------------------------------------------------------------- >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=1655442&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:27
|
Feature Requests item #1674180, was opened at 2007-03-05 15: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=1674180&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: Jonhnny Weslley (jweslley) Assigned to: David Saff (dsaff) Summary: To support test methods with injection of parameters Initial Comment: Recently, I need of parameterized test methods, then used a Parameterized runner, but this uses constructor injection of parameters, and my unit test has many test methods with distinct types. Then I was create a ParameterizedMethod runner, which uses method injection of parameters - parameterized test methods. The parameterized test methods requires a ParametersSource annotation, this annotation requires the parameters source method name. The parameters source method to must be no arguments, public, static, and, finally, to return a Collection or a array. However, to support this feature requires two little changes in junit: 1) org.junit.internal.runners.MethodValidator class renamed to TestClassValidator. The TestClassValidator is more extensible than MethodValidator, which allow to create a ParameterizedMethodValidator class, required for the new feature. 2) To add the TestClassValidator's factory method - createTestClassValidator method - at org.junit.internal.runners.TestClassRunner class. The junit-parameterized-method.zip file has a copy from TestClassRunner class - called TestClassRunner2 - added of the createTestClassValidator method. USAGE: ... @Test @ParametersSource("numbersEq") // refer to numbersEq method public void checkGreaterThan(int x, int y) { assertTrue("x lower than y", x < y); } public static Integer[][] numbersEq() { return new Integer[][] { {1, 2}, {2, 3}, {3, 4}, {4, 5}, {5, 6}}; } ... ---------------------------------------------------------------------- >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: Alex (toalexsmail) Date: 2008-03-12 21:34 Message: Logged In: YES user_id=2034775 Originator: NO See related http://sourceforge.net/tracker/index.php?func=detail&aid=1626414&group_id=15278&atid=365278 ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2007-04-12 20:12 Message: Logged In: YES user_id=325156 Originator: NO Jonhnny, could you attach your changes as a patch so we can review it more easily? Thanks. ---------------------------------------------------------------------- Comment By: Jonhnny Weslley (jweslley) Date: 2007-04-09 17:35 Message: Logged In: YES user_id=1627927 Originator: YES I realize some refactorings in junit-4.3.1 to support this feature. Changes: - Replacement of org.junit.internal.runners.MethodValidator class by org.junit.internal.runners.TestClassValidator class. - Introduce factory method createTestClassValidator in org.junit.internal.runners.TestClassRunner class - Introduce runner: org.junit.runners.ParameterizedMethod - Include a sample test class: org.junit.runners.IntDateTimeTest File Added: junit.jar ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1674180&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:27
|
Feature Requests item #1687449, was opened at 2007-03-24 15:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1687449&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: Tom Roche (tlroche) Assigned to: Nobody/Anonymous (nobody) Summary: allow non-constant arguments to timeout Initial Comment: http://tech.groups.yahoo.com/group/junit/message/19139 >> I want to be able to read timeout values from >> Preferences. With JUnitPerf and JUnit 3.x I can >> decorate a test like >> + public Test suite() throws FooException { >> + Test testCase = new TestFoo("testFoo"); >> + return new TimedTest(testCase, getMaxElapsedTime(), false); >> + } >> With JUnit 4 I'd like to be able to do >> something like >> - @Test(timeout=getMaxElapsedTime()) >> - public void testFoo throws FooException { >> - ... >> - } >> but can't. http://tech.groups.yahoo.com/group/junit/message/19140 > There's no way to do this using the built-in > runners, although a custom runner could do it. > If you submit a feature request to SourceForge, > I'd be happy to take another look at it. Thanks, > David Saff ---------------------------------------------------------------------- >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: Mahmood Ali (mali999) Date: 2008-07-18 23:10 Message: Logged In: YES user_id=2152267 Originator: NO This is not possible. The timeout value needs to be a compile-time constant expression, like any other annotation value (JLS 9.7, 15.28). Java specification disallows: @Test(timeout=getMaxElapsedTime()) ... but allows: final int MAX_ELAPSED_TIME = 1; @Test(timeout=MAX_ELAPSED_TIME) ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1687449&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:27
|
Feature Requests item #1742040, was opened at 2007-06-23 12:51 Message generated for change (Comment added) made by sf-robot 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: Closed 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: 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: Anli Shundi (anshnd) Date: 2009-11-16 18:57 Message: Please vote at http://github.com/KentBeck/junit/issues/#issue/44 ---------------------------------------------------------------------- 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: Nobody/Anonymous (nobody) Date: 2009-06-03 08: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 14: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 11: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 22: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 19: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 18: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 21: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 21:34 Message: Logged In: YES user_id=168544 Originator: NO +1 for @TestName ---------------------------------------------------------------------- Comment By: Jeremy Carroll (jeremy_carroll) Date: 2007-08-03 09: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 09: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 17: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 21: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 19: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-12-01 02:20:27
|
Feature Requests item #1707887, was opened at 2007-04-26 08:09 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1707887&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: Torsten Marek (shlomme) Assigned to: Nobody/Anonymous (nobody) Summary: [Patch] Runner for mixing parameterized and normal tests Initial Comment: Hi, the attached archive contains a special runner called "EnhancedRunner" that supports mixing "traditional" test cases (public void, no arguments) with parameterized test cases, which can now be public void methods that take arguments. An example: class StringTest { @Test public void testConcat() { assertEquals("ab", "a" + "b"); } @ParamTest("strings") public void testLength(String s, int length) { assertEquals(length, s); } public static Collection<Object[]> strings() { return Arrays.asList(new Object[][] { {"foo", 3}, {"foo bar", 7}, {"", 0}}); } } The runner will collect methods with @Test annotations as well as @ParamTest ones. For a @ParamTest, it will use the methods whose name is contained in the value (which has to be a public static method that returns an Iterable<Object[]>) to obtain the arguments for the invocations. This approach has several advantages over the "Parameterized" runner in JUnit 4.x: - normal tests and parameterized tests can be mixed in one class, no need to create several separate unit test classes - the method is invoked directly instead of first creating the class - in this case, the test class needs to keep references to the parameters. Of course, if a whole test suite depends on parameters, the Parameterized runner is to be prefered. This parameters are also put into the description of the test, thus it is possible to see which set of parameters triggered a test failure. This would also be a useful enhancement for the Parameterized runner. A helper method to neatly format argument lists is contained in the helper class ParameterUtils, which also contains some methods to split vararg arrays of length n*m into n arrays of length m, which is useful for creating argument lists. Currently, there is one external dependency on StringUtils.join from Commons Lang, which can easily be removed. with best regards, Torsten Marek, FAST Search & Transfer ---------------------------------------------------------------------- >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: CoSoCo (cosoco) Date: 2008-08-28 13:23 Message: Logged In: YES user_id=1040495 Originator: NO Very nice work !!! I like to suggest, to change the annotation identifier from: @ParamTest to: @ParamsTest Regards, Ulf ---------------------------------------------------------------------- Comment By: FARKAS Mt (fmate14) Date: 2008-03-15 14:40 Message: Logged In: YES user_id=1698060 Originator: NO Very good idea, thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1707887&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:26
|
Feature Requests item #1804350, was opened at 2007-09-28 14: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=1804350&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: David Saff (dsaff) Assigned to: David Saff (dsaff) Summary: Allow constructor parameters in Theories Initial Comment: Currently, the Parameters runner forces parameters to be passed as constructor parameters, and the Theories runner forces parameters to be passed as method parameters. Passing Theory parameters as constructor parameters can allow common assumptions to be grouped in the constructor or @Before statements, like: @RunWith(Theories.class) public class PositiveInts { private int x; public PositiveInts(int x) { assumeTrue(x > 0); this.x = x; } @Theory public void haveAPostiveSquare() { assertTrue(x*x > 0); } } ---------------------------------------------------------------------- >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=1804350&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:26
|
Feature Requests item #1748683, was opened at 2007-07-05 18:55 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1748683&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: Christian Nelson (xianpants) Assigned to: Nobody/Anonymous (nobody) Summary: Improve support for grouping/partitioning tests into suites Initial Comment: Often, there are a variety of types of tests on a project, from true unit tests to integration tests which span the spectrum from "almost a unit test" to "end-to-end integration test". There's value in all of these types of tests and there are many extensions to junit for supporting them (dbunit, spring's test case hierarchy, web tests, etc). Despite the name, junit is really a harness for running all types of tests (whether or not that was the original intention). We've run into the situation where we need to partition our tests into multiple suites. On my current project we have a set of tests which need to be run from a specific machine due to the fact that they reach out to external systems that only accept connections from preset ip addresses. These tests are integration tests which we run from time to time, not with every build. It's easy to imagine other examples of suites: unit tests which run uber-fast and integration tests which run more slowly. I find junit's suite support to be pretty poor and there are a number of real problems with it, including: * @SuiteClasses(TestClass1.class, ...) is cumbersome for large sets of classes. * @SuiteClasses(TestClass1.class, ...) is error-prone because it's easy to forget to include a new test case in the suite. * @RunWith(Suite.class) leads to some tests being run multiple times when you "run all tests" from ant/maven/an ide. We want tests to run as fast as possible; running some of them twice (or more) doesn't help. I think all of these problems directly stem from the composite pattern applied to test organization. The fact that something (a class annotated with @RunWith(Suite.class)) outside of the tests does the grouping doesn't feel natural to me. I really think of it as every test class (or optionally test method) may optionally be part of one or more named groups, and the assignment happens in the test itself, not some external suite class. Here's how I'd do it: 1. Test runners (ant, maven, idea, eclipse, etc) could accept an optional parameter which specifies which group(s) are to be run. If none are specified, then all tests are run. 2. These changes to existing annotations could accommodate this model: Applied to either test methods or test classes... when applied to a test class, it propagates to all of the test methods in the class. @Test(group = "online tests") @Test(groups = {"integration tests", "online tests" }) [Yes, the only difference between the two is the plurality and helper so that an array of one isn't necessary.] 3. Grouping would have to become a first class concept in all of the test runners (or the default/topmost at the very least). Note that TestNG has support for the kind of grouping I'm describing (see references). I'm a loyal user of JUnit and prefer it to TestNG because of its simplicity and better (build-in) tool support (everyone ships with junit support). However, this is one feature that is just poorly implemented in JUnit and I think needs some attention so that is becomes both easier to use and more useful. I think it can be implemented in such a way that the old functionality could remain for those who use it, users wouldn't /have/ to use the new group features, and users who wanted it could use it. What do you think? Christian References: http://tech.groups.yahoo.com/group/junit/message/19521 http://testng.org/doc/documentation-main.html#test-groups ---------------------------------------------------------------------- >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: Thomas Steininger (steininger) Date: 2008-04-08 14:50 Message: Logged In: YES user_id=1323884 Originator: NO i also vote for this feature-request. is there any argument against it? ---------------------------------------------------------------------- Comment By: Alex (toalexsmail) Date: 2008-03-12 21:48 Message: Logged In: YES user_id=2034775 Originator: NO I have some related request. See http://tech.groups.yahoo.com/group/junit/message/20357 for discussion. AFAIK this feature is replacement to TestSuite in JUnit 3.8. But it is less flexible then TestSuite. In JUnit 3.8 you have an option to add some methods from one class and some methods from the another class. See also related topic "Filter improvement". I think this functionality should be available also here, perhaps, with futher improvement, such as use of patterns. At least one should be able to run couples of methods from the given class. When I have some related tests I preferred to run them altogether and to look what is fails. It helps me both to save the time and to identify the problem. I feel lack of this in JUnit 4. ---------------------------------------------------------------------- Comment By: David Saff (dsaff) Date: 2007-07-09 15:50 Message: Logged In: YES user_id=325156 Originator: NO Let's further discuss this on ju...@ya..., and post a summary here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1748683&group_id=15278 |
From: SourceForge.net <no...@so...> - 2009-12-01 02:20:26
|
Feature Requests item #1846238, was opened at 2007-12-07 14:54 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1846238&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: Nicholas Stuart (ender_01) Assigned to: Nobody/Anonymous (nobody) Summary: Centralized Custom Annotation Initial Comment: Using Springs new test framework I thought it would be a nice feature to be able to have our own centralized annotation we could use to hold all the configuration information. Yes you can do this with a base class and extend that, but would be nice to be able to avoid it. I think the only thing needed from JUnit in order to do this is to be able to put @RunWith on an annotation and have it work when you put that annotation on a class. See attached file for example. Also see related spring task at: http://opensource.atlassian.com/projects/spring/browse/SPR-4227 ---------------------------------------------------------------------- >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=1846238&group_id=15278 |