ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariano Benitez <mari...@fuegolabs.com>
Subject Re: can I change junit runner main class
Date Wed, 11 Feb 2004 15:25:11 GMT

>This sounds simple to do inside the task, simply change
>
>    private CommandlineJava commandline = new CommandlineJava();
>
>to
>
>    private CommandlineJava commandline = newCommandlineJava();
>
>with
>
>    protected CommandlineJava newCommandlineJava() {
>        return new CommandlineJava();
>    }
>
>  
>
basically since you are defining the commandLine className in the 
contructor, it would not be much different to defining the commandLine 
in the contructor

like
    public JUnitTask() throws Exception {
       createCommandlineJava();
        commandline
            
.setClassname("org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner");
    }

ultimately you could replace direct usages of the commandline variable 
by an accessor, so I just need to override the accessor. Whatever you 
decide, any of these options solve my problem.

I could upload a patch to bugzilla if you need to, but the change is 
simple enough.

>While we are at it, we may as well review the JUnitTask to see whether
>we should change some other things, now that we'd consider subclassing
>the task something we expect to happen.
>

I must make clear (I think I have already done so) that the usage we 
need of JUnit is quite unique (bah, I guess), since we need to launch 
java with a minimal classpath and inside our main class create a 
classloader where the real main class gets executed.

As you can imagine this applies to forked tests only.

My experience tells me that for forked tests, you get a lot of control 
if you can extends CommandlineJava to build the command you require, 
that way you can adapt the attributes of the task to whatever you need 
to execute.

 I guess that by having executeAsForked and executeInVM as private do 
not let much space to extension, but I think they do not have many 
things that are exendable, may be by splitting some part of 
execute(JUnitTest test) to separate the setting of the dirs (first 2 
ifs) from the execution, and also split the last part where you decide 
if to fail or not based on the result, leaving just this piece for 
extension:

        // execute the test and get the return code
        int exitValue = JUnitTestRunner.ERRORS;
        boolean wasKilled = false;
        if (!test.getFork()) {
            exitValue = executeInVM(test);
        } else {
            ExecuteWatchdog watchdog = createWatchdog();
            exitValue = executeAsForked(test, watchdog);
            // null watchdog means no timeout, you'd better not check 
with null
            if (watchdog != null) {
                wasKilled = watchdog.killedProcess();
            }
        }

this would help to extend the way you execute the tests.

This is the analysis I can make, please consider it not thorough cause I 
cannot dedicate a lot of time to this (I'm just trying to migrate the 
version of ant in my company!)


Cheers,
MAriano

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message