If I might interject a comment: > > Disadvantages of Cactus > > ... > > - requires special test case super class > > yep. Not sure this is really a problem though. Do you have an issue in > mind ?
Surprisingly, this turns out to be a annoying encumbrance. Two examples: 1) Some tools with built-in junit support key off of a TestCase subclass and don't accomodate a ServletTestCase subclass. E.g., the IntelliJ idea IDE recognizes any TestCase subclass as a candidate under the Run>Junit Tests menu pick, but will only recognize a ServletTestCase if it supplies a suite() method. Granted, this is arguably a defect of the idea tool, but the point is that any variation from the standard junit class structure will inevitably affect the test tool user in unpredictable ways. 2) It is desirable to make the test infrastructure (remote vs. local) orthogonal to the test content. E.g. I use an application framework that insulates business logic from it's distribution and persistence characteristics--local, EJB, MDB, XML. A class MyClass with business logic could run under several different contexts depending on an external configuration. The class MyClass can be tested locally with junit class MyClassTest. However, I have found no way to reuse MyClassTest with cactus. I must instead maintain two test classes, MyClassLocalTest and MyClassServerTest, with identical content but a different superclass, TestCase and ServletTestCase, resp. Note that extension of an abstract base class is not an option, since the base class must make a discrete superclass choice. Similarly, delegation to a test helper class with the test content breaks the junit introspection paradigm. Cactus derivation from a special superclass falls under the category of an annoyance rather than a major problem, but I thought that some clarification might be useful. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
