Hi Fred, I have been thinking a bit about all this ... and I now understand that there are some cases when it is useful to run the same test both on the client side and in the server (like when you're doing class loader stuff, etc). In addition to performing "double-checks" ...
WRT your proposition: Proposition 1 : TestSuite This is a good idea. It will probably work (I still need to prototype it though). The only issue is that you would have to create your test suite in another class as you want to reuse the same class both when using Cactus and pure JUnit. That's a limitation but it is probably acceptable. Proposition 2: Using Aspect I would prefer not to do that as AOP is still not very common, tools are lacking and I do not want users to have to use ajc to compile their test code! Proposition 3: ServletTestRedirector This one, I do not understand. Whatever "tool" is used, it has to be run before the test runner kicks in and starts the testXXX() test. The only options available are : in a TestSuite as in proposition 1 or in a TestRunner itself. This is also a possibility that I would like to explore. However, I tend to prefer the TestSuite solution as I can still use existing test runner to run my tests. BTW, with solution 1, it is probably possible to still have access to the container implicit objects as the TestSuite would wrap all test classes in a ServletTestCase, etc (as is the case now). Thus, in a given test you would still be able to write: ((ServletTestCase)this).request to get access to the HttpServletRequest (for example). Thanks for the ideas! I'll definitely take them into account for Cactus 1.5 or later. Cheers, -Vincent PS: If you wish to participate and implement these ideas, please go ahead! > -----Original Message----- > From: Fred Loney [mailto:[EMAIL PROTECTED]] > Sent: 26 August 2002 19:49 > To: Vincent Massol; 'Cactus Users List' > Cc: 'Oliver Rossmueller' > Subject: Re: JUnitEE and Cactus > > > 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]>
