views:

466

answers:

3

When loading all unit tests in a package, the make task throws a java.lang.OutOfMemoryError: Java heap space error.

If I run all the tests in each subpackage, though, all tests load and complete just fine. It is only when I try to run all tests in the parent package that the OOM error occurs.

I don't think this problem should be solved by tweaking VM parameters. I tried increasing the maximum heap and perm size, and it didn't solve the problem.

This leads me to believe there is some problem garbage collecting between loading tests in different packages, or that there is some too-eager class loading going on.

Is there a JUnit setting that could take care of these issues, or is the problem going to have to be solved by changing or adding code in the test cases?

+1  A: 

The GC runs when the CPU has spare time or the free memory is low. If your tests crash, you might have a memory leak somewhere. (Yes they exist in java too)

Have a look for circular references and static classes/variables.Theses are IIRC common reasons for memory leaks. You should also have a look at jconsole.

Patrick Cornelissen
+5  A: 

You must set all fields of the test classes to null in tearDown().

The reason is that JUnit instantiates one instance of the test class per test. It keeps that instance around for the whole time to save the results of the test (success, failure, stack trace). So if you use fields, they will stay and you'll run out of memory.

Aaron Digulla
Cool, I'll test this fix first.
Getimoliver
Unfortunately, this did not solve the problem. doesn't tearDown() only get called after all the classes have been loaded, and tests begin to run? The OOM error I'm seeing is happening during the Make task, before the tests even start to run.
Getimoliver
No, tearDown is called after each individual test. But I missed "in the Make task". What make task are you talking about? Are you using Ant? Or GNU Make?
Aaron Digulla
I am using Ant.
Getimoliver
Okay. Does ant even get to starting the unit tests? Run it with -d to see where it really fails.
Aaron Digulla
A: 

I experienced a similar problem using TestNG and traced it to the amount of log information I was generating to the console. Once I'd reduced this I was able to run my test suite without memory problems.

Adamski