I find the general approach quite brilliant. It might be the right answer to the bigger problem of testing class loader related issues with Junit instead of through a static main method. However, the approach has the disadvantage of displacing some of the test logic into junit. Of course, the displacement in logic is unavoidable by construction.
You have either created a new testing idiom to be followed by many java developers, or alternatively yet another indirection which will make the testing logic inscrutable for mere mortals. Anyway, the promise seems well worth the risk.
At 01:53 PM 6/29/2005, Simon Kitching wrote:
Hi All, Quite a few of the JCL unit tests need to be run with specific classloader hierarchies set. The current solution is to avoid running the standard junit.textui.TestRunner class and instead run the org.apache.commons.logging.Wrapper class which sets up any custom classpath needed then executes the test. However this solution moves the critical information about what is being tested out of the TestCase classes and into a combination of the Wrapper class and the build.xml file. This makes it hard to understand the testcase code. It also makes the build.xml file quite complicated. It makes it impossible to use the <batchtest> junit task - which Maven depends on, therefore also making it impossible to use Maven to run the tests. It also provides insufficient control over classpaths etc. to implement the existing tests in the "demonstration" directory as unit tests (in particular it doesn't provide parent-first/child-first options for classloader behaviour). I have come up with an alternative solution: have the testcase classes create customised TestSuite objects instead. Here's a modified org.apache.commons.logging.log4j.CustomConfigTestCase class:
[cut]
Simon
-- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
