> In my experience, > the tests you wanted to do on your class are completely different in > you're testing the logic or if you're testing the interaction with the > container and other classes... If you're > talking about simple java beans with no interaction with the servlet > engine, then there is really no point in testing them in Cactus.
It is a regression test of sorts: I develop a class locally and a corresponding TestCase. Now I want to know whether the class works in a servlet. Given a framework that isolates logic from distributed context, I don't need to change either the class or the test behavior to run the class in a servlet. But I must duplicate the TestCase as a ServletTestCase to run the test remotely. Note that because of the framework context the class will take a very different execution path depending on whether it is run locally or remotely, even though the class code is not changed. > I'm open to suggestions. What do you propose ? Off the top of my head: 1) A ServletTestSuite that extends a TestSuite to do cactus redirection on the run method but delegates to the standard suite subtasks for test logic, or 2) A ServletTestAspect that conditionally inserts cactus redirection code into a standard TestCase, or 3) A ServletTestRedirector tool that introspects a standard TestCase and performs the redirection without code modification. Of course, none of these approaches enables TestCase code interaction with the servlet context and the extended cactus functionality, but that is acceptable for such a regression test. Not coincidentally, these three approaches might also be candidates for finding some commonality between Cactus and JunitEE, which still seems worthy of further investigation. It's tough to choose between two such worthy tools. Not that I'm complaining--I wish all my problems were like that! -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
