views:

1204

answers:

6

I am running my junit tests via ant and they are running substantially slower than via the IDE. My ant call is:

    <junit fork="yes" forkmode="once" printsummary="off">
        <classpath refid="test.classpath"/>
        <formatter type="brief" usefile="false"/>
        <batchtest todir="${test.results.dir}/xml">
            <formatter type="xml"/>
            <fileset dir="src" includes="**/*Test.java" />
        </batchtest>
    </junit>

The same test that runs in near instantaneously in my IDE (0.067s) takes 4.632s when run through Ant. In the past, I've been able to speed up test problems like this by using the junit fork parameter but this doesn't seem to be helping in this case. What properties or parameters can I look at to speed up these tests?

More info:

I am using the reported time from the IDE vs. the time that the junit task outputs. This is not the sum total time reported at the end of the ant run.

So, bizarrely, this problem has resolved itself. What could have caused this problem? The system runs on a local disk so that is not the problem.

+1  A: 

Difficult to tell with that information. First thing I would do is look at the test results and determine if all the individual tests are running uniformly slower or if it can be narrowed down to a certain subset of test cases.

(The zero'th thing I would do is make sure that my ant task is using the same JVM as Eclipse and that the classpath dependencies and imported JARs are really and truly identical)

Eric Asberry
The jars and JVM are the same. It seems that across the board any test that runs in < 1.0 second in an IDE runs in 3.5-4.5 seconds via ant.
Alex B
+1  A: 

Maybe you are seeing that because Eclipse do incremental compiling and Ant don't. Can you confirm that this time is wasted only in the test target?

Kind Regards

marcospereira
+2  A: 

Here's a blind guess: try increasing the maximum heap size available to the forked VM by using a nested <jvmarg> tag to set the -Xmx option.

bsanders
I was going to suggest this, along with increasing the heap size available to Ant itself, as well.
matt b
A: 

I have the same issue, although not through ant. I am attempting to run the unit tests via the textui TestRunner (junit.textui.TestRunner, JUnit 3.8.1). Nearly every test is at least twice as slow, and one particular test is extremely slow (~4 seconds in Eclipse, 300 seconds from the textui runner).

I have not yet tracked down the problem. I have attempted to sprinkle some debug code throughout, but there is no single culprit for the slow down. It appears that all operations are slower across the board.

A: 

For the record, I found my problem. We have been using a code obfuscator for this project, and the string encryption portion of that obfuscator was set to "maximum". This slowed down any operation where strings were present.

Turning down the string encryption to a faster mode fixed the problem.

James Van Huis
+1  A: 

I'm guessing it's because your antscript is outputing results to XML files, whereas the IDE is keeping those in memory. It takes longer to write a file than to not write a file.

todir="${test.results.dir}/xml"

That's the part of the <batchtest> call that tells it to stick the results into that directory. It looks like leaving it off just tells it to stick the results in the "current directory", whatever that is. At first glance I didn't see anything to turn it all the way off.

Risser