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.
Vemund
