The use of PathableClassLoader is not required to use this class, but it is expected that using the two classes together is common practice.
This class will run each test methods within the specified TestCase using the specified context classloader and system classloader. If different tests within the same class require different context classloaders, then the context classloader passed to the constructor should be the "lowest" one available, and tests that need the context set to some parent of this "lowest" classloader can call
// NB: pseudo-code only setContextClassLoader(getContextClassLoader().getParent());This class ensures that any context classloader changes applied by a test is undone after the test is run, so tests don't need to worry about restoring the context classloader on exit. This class also ensures that the system properties are restored to their original settings after each test, so tests that manipulate those don't need to worry about resetting them.
This class does not provide facilities for manipulating system properties; tests that need specific system properties can simply set them in the fixture or at the start of a test method.
Important! When the test case is run, "this.getClass()" refers of course to the Class object passed to the constructor of this class - which is different from the class whose suite() method was executed to determine the classpath. This means that the suite method cannot communicate with the test cases simply by setting static variables (for example to make the custom classloaders available to the test methods or setUp/tearDown fixtures). If this is really necessary then it is possible to use reflection to invoke static methods on the class object passed to the constructor of this class.
This class cannot control the system classloader (ie what method ClassLoader.getSystemClassLoader returns) because Java provides no mechanism for setting the system classloader. In this case, the only option is to invoke the unit test in a separate JVM with the appropriate settings.
The effect of using this approach in a system that uses junit's "reloading classloader" behaviour is unknown. This junit feature is intended for junit GUI apps where a test may be run multiple times within the same JVM - and in particular, when the .class file may be modified between runs of the test. How junit achieves this is actually rather weird (the whole junit code is rather weird in fact) and it is not clear whether this approach will work as expected in such situations.
| |