Bug 34748 - [PATCH] JUnit Task enhancement to allow a single test method to be specified
Summary: [PATCH] JUnit Task enhancement to allow a single test method to be specified
Alias: None
Product: Ant
Classification: Unclassified
Component: Optional Tasks (show other bugs)
Version: 1.6.3
Hardware: All All
: P2 enhancement with 2 votes (vote)
Target Milestone: 1.8.2
Assignee: Ant Notifications List
Keywords: PatchAvailable
Depends on:
Reported: 2005-05-04 23:29 UTC by John Sisson
Modified: 2010-06-11 12:39 UTC (History)
4 users (show)

[PATCH] JUnit - add ability to execute a single test method (14.81 KB, patch)
2005-05-04 23:31 UTC, John Sisson
Details | Diff
[PATCH] JUnit - add ability to execute a single test method (17.84 KB, patch)
2005-05-08 06:25 UTC, John Sisson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Sisson 2005-05-04 23:29:42 UTC
Currently, when a JUnit test is executed via the Ant JUnit task ( 
http://ant.apache.org/manual/OptionalTasks/junit.html ), a number of test
methods in the test class are executed and there is no support in the JUnit task
for instructing JUnit to execute a single test method (like the way JUnit
provides this functionality via the -m parameter in the junit.textui.TestRunner

This patch (generated against the ANT_16_BRANCH in CVS) provides the ability to
specify a test method name to be executed in the new "method" attribute of the
nested "test" element in the <junit> ant task.

Reasons why enhancing the Ant JUnit task to allow the execution a single test
method is desirable:

* When a test method fails, you can run the failing test method under the Java
debugger without having to wait for the other test methods to complete
(especially where some of the other tests are long running).
* Ability to quickly test code changes that fix a failing test
* Ability to run under a Java profiler, a single test method that appears to be
running slower than expected (without the overhead of running the profiler
whilst other test methods are being executed).
* Speeds up the test/debug cycle when you are running on a busy system or slow
* No need to make code changes to force one test to be run when you want to
debug a single test.

The patch also adds 2 tests for the new functionality, which have been executed
along with the existing Ant JUnit tests in the ANT_16_BRANCH.
Comment 1 John Sisson 2005-05-04 23:31:55 UTC
Created attachment 14935 [details]
[PATCH] JUnit - add ability to execute a single test method
Comment 2 John Sisson 2005-05-04 23:34:39 UTC
FYI.. If this patch is accepted, I plan to submit a related patch to the Apache
Maven project's Test plug-in that allows this new functionality to be used in a
command like the following:

maven -o -Dtestcasecom.mycompany.MyTest -Dmethod=testSomething test:single

or under a debugger..

maven -o -Dmaven.junit.jvmargs="-Xdebug -Xnoagent -Djava.compiler=NONE
-Dtestcasecom.mycompany.MyTest -Dmethod=testSomething test:single
Comment 3 Peter Reilly 2005-05-05 10:59:09 UTC
* please use ant head and not ant_16_branch
* the patch changes a public constuctor - JUnitTest
Comment 4 John Sisson 2005-05-08 06:25:18 UTC
Created attachment 14963 [details]
[PATCH] JUnit - add ability to execute a single test method

Attached patch (generated against cvshead) for review that obsoletes the
existing patch that I submitted (that was generated against the ant_16_branch).

The 'since' information in the doc & javadoc changes assume that it will be
included in Ant 1.7.

I have checked that no public method signatures have been changed.

Also see the two // TODO comments - delete them if you don't think a different
message should be logged (I wasn't sure whether changing the messages could
impact some program that relies upon the format of the log messages).
Comment 5 John Sisson 2005-06-16 07:10:07 UTC
Any chance someone could review this patch. Thanks.
Comment 6 Marian Petras 2008-04-16 05:36:17 UTC
The patch looks good at the first sight (but no thorough check yet).

I suggest that it should be possible to specify multiple method names.
Comment 7 Jesse Glick 2008-04-16 08:30:48 UTC
Would also want to ensure that this works sanely with JUnit 4 tests using annotations.

I presume that if the test class has a

public static Test suite() {...}

method, the parameter would be ignored?
Comment 8 Marian Petras 2008-04-24 05:05:08 UTC
Why do you think it should be ignored? I think it should not be ignored.
Comment 9 Jesse Glick 2008-04-24 10:10:24 UTC
If you have a static suite method, then that is going to specify a list of tests to run (which may in fact live in other classes, etc.), rather than the default suite which contains all test* methods from the current class. Using suite() would directly contradict the intent to run a single test case from this class, as I understand it.
Comment 10 Marian Petras 2008-04-25 08:53:14 UTC
I understand what the suite() method is for but I still I do not understand what would be the reason for ignoring the method name if the suite() method is present. What would be the benefit?
Comment 11 Jesse Glick 2008-04-25 12:32:50 UTC
If you have

public class MyTest extends TestCase {
    public void test1() {...}
    public void test2() {...}

then it makes sense to ask to run test1 by itself, or test2 by itself; the implicit default suite being run is test1 followed by test2, which the environment is just overriding. But if you have

public class MyTest extends TestCase {
    public MyTest(String n) {
    public static Test suite() {
        TestSuite suite = new TestSuite();
        suite.addTest(new MyTest("one"));
        suite.addTest(new MyTest("two"));
        // stuff in other classes too, maybe parametrized:
        suite.addTest(new MyOtherTestSuite());
        return suite;
    public void one() {...}
    /* expected to be run immediately after one() */
    public void two() {...}

then the suite() method gives the definitive answer to what tests should be run and in which order. In this case it is senseless to try to run a single test method from the environment.
Comment 12 Marian Petras 2008-04-25 13:13:29 UTC
I understand. But I still consider it a needless restriction - something like "I assume you will not need to do this so I will not allow you to do it." In other words: Why it is better to have this restriction in place than not to have it? What would be the negative implications if the restriction is not applied?

Another reasoning:
If a test class does not contain any suite() method, then the set of test methods is defined. By specifying a particular method name (or names), I override this selection. Why it should be any different if the suite() method is present?
Comment 13 Jesse Glick 2008-04-25 14:18:26 UTC
Well, you can try to select some "public void test*()" methods to run even if there is a suite() method, but there might not be any such methods (they might be implemented in another class, or named differently), and they might not run correctly. I guess it is harmless to try.
Comment 14 David Saff 2008-09-15 06:14:00 UTC
What's the current thinking on this patch?  Thanks,

   David Saff
Comment 15 Jesse Glick 2010-02-05 16:59:06 UTC
FYI: a variant of this patch (against 1.7.1) is shipped with NetBeans 6.8 to permit single test method execution from inside the IDE. (Versioned project build scripts do not use this feature - only available for "quick run" mode with a special transient script.) https://svn.apache.org/repos/asf/ant/core/branches/run-single-test-method/ holds an update of the patch against 1.8.0.
Comment 16 Jesse Glick 2010-05-03 13:49:08 UTC
Branch updated to 1.8.1.
Comment 17 Jesse Glick 2010-05-28 13:20:30 UTC
I would like to merge the run-single-test-method branch for 1.8.2. It has been in use for quite some time as a binary patch in NetBeans, for rerunning failed tests. Any objections to merging it?
Comment 18 J.M. (Martijn) Kruithof 2010-05-29 02:38:55 UTC
(In reply to comment #17)
> I would like to merge the run-single-test-method branch for 1.8.2. It has been
> in use for quite some time as a binary patch in NetBeans, for rerunning failed
> tests. Any objections to merging it?

Jesse, please do merge
Comment 19 Jesse Glick 2010-06-11 12:39:34 UTC
merged: rev 34748