db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vemund Ostgaard <Vemund.Ostga...@Sun.COM>
Subject Re: JUnit memory consumption
Date Wed, 24 Oct 2007 13:35:51 GMT
Kathey Marsden wrote:
> Upon more research it seems that JUnit creates one instance of each 
> test class per fixture and keeps that reference until the end of the 
> suites.All run.  That means any state in the test hangs around as 
> well, which slowly adds up as the test runs. This is particularly 
> problematic for tests such as ClosedObjectTest which ends up with 3150 
> instances + state for each:
Thanks for bringing this up Kathey, I guess we will keep sliding into 
this problem again and again without a more long term solution.
> Options to reduce footprint include:
> - Make sure tests have tearDown() methods that null out fields.
> -  Rework  tests such as ClosedObjectTest  to not have so many fixtures.
> - Make a request to JUnit that the Suite  dereferences the test after 
> it runs.
> - Make the tearDown method in BaseJDBCTest null out fields. (I think 
> this means that fields for tests would have to be public.)
> - Something else?
> Thoughts on this are greatly appreciated.
I guess it might be a possibility to run the smaller subsuites one at a 
time in different junit-executions, getting a fresh jvm each time, 
instead of the monolithic suites.All. As far as I can understand, this 
is how it is currently done if you run the junit tests using ant.

Actually, looking at the build.xml I see that the autoloading tests have 
to be executed in their own jvm for other reasons. Having some way to 
execute the tests in different jvms also when running from the jar-files 
would make it possible to run these tests as well. I would suspect that 
other tests in the future would also need their own "fresh" jvm.

Finally, when we at some point are able to configure portnumber for the 
junit runs, it would be possible to run several of the subsuites in 
parallell if we ran them in different jvms, and in this way probably cut 
the time required to run "suites.All" a lot.

So, maybe we just need a utility or testrunner of some sort that could 
execute the subtsuites in suites.All in different jvms.


View raw message