| Executing junit tests with differing classpaths | Executing junit tests with differing classpaths 2005-06-26 - By Simon Kitching
Hi,
At the jakarta-commons-logging project we need to be able to execute
various unit tests with different classpaths set.
As an example test Test1 may need to have
parent-classloader: lib1.jar
child-classloader: lib2.jar, test-classes-dir
The old way of executing unit tests is by using a target which has a
<java> task that executes junit.textui.TestRunner. Currently
commons-logging uses a similar approach, but executes a custom class
that:
* sets up classloaders with custom paths appropriate for the test
* loads class junit.textui.TestRunner into a classloader
* calls TestRunner.main to execute the test
The test class then sees exactly the classloader hierarchy that is
needed for the test.
Unfortunately this means that we need to explicitly execute each
possible testcase via a separate <java> task (specifying our
classloader-tweaking class as the target). TestSuite classes that return
Suite objects containing multiple classes can be defined, but obviously
only testcases that are expecting the same classpath can be combined in
this way (and it's not a very elegant solution anyway).
The <junit> and <batchtest> tasks can make life much easier. But
unfortunately as far as I can see these tasks provide no ability to
insert our custom classloader-configuration step before each test is
run.
And of course because Maven's maven-test-plugin is based on <junit> and
<batchtest> we can't use Maven the standard maven process to run our
unit tests.
Am I right in thinking that the <junit> task provides no way for the
classloader setup in the forked JVM to be tweaked before the test is
executed?
If so, would anyone be interested in extending Ant with a hook to allow
this? I *think* it's just a matter of providing the <junit> task with an
attribute "testRunnerClass" which defaults to
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner
rather than hardwiring that string into the JUnitTask class.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
|
|
 |
