Hi Fred, As you mention, JUnitEE is currently the best option for satisfying this particular requirement. However, I'd like to also support this requirement in Cactus as I would like to make Cactus the de facto standard for server side testing... :-)
I think I have found the way to support your requirement easily in Cactus! It works as follows: * Special XXXTestSuite classes (ex: ServletTestSuite) * In XXXTestSuite.addTest(Test)/XXXTestSuite.addTestSuite(Test), instead of doing a new of the passed Test object, it does a new of XXXTestCase(Test), thus wrapping the passed Test object. That's all! It's completely transparent for the end user. Thanks -Vincent > -----Original Message----- > From: Fred Loney [mailto:[EMAIL PROTECTED] > Sent: 23 February 2003 00:46 > To: Cactus Users List > Subject: Re: Single test class for both local and remote > > I suspect that JUnitEE is a preferable vehicle for satisfying this > particular requirement, but I'm not qualified to judge. If it is > desirable to support the requirement in cactus, then the only way I know > to accomplish option 2b using TestCase objects rather than > CactusTestCase objects is to preprocess the client source with aspectj. > This alternative does indeed entail additional user set-up. But since > cactus is essentially an aspect, it is not unreasonable to offer cactus > functionality as an aspect. > > It would then be straightforward to wrap the aspect in a separate > CactusTestCase class so that the user can have it both ways. Thus, the > Cactus distro would include: > > 1) a CactusAspect ajc aspect that can be used to introduce cactus > functionality into an arbitrary JUnit TestCase class, and > > 2) a CactusTestCase java class that is merely a shell processed by the > CactusAspect. > > In order to use (1), the user integrates CactusAspect into his build as > desired. > > In order to use (2), the user extends CactusTestCase rather than > TestCase and sets the "cactus.type" system parameter as you describe. > > CactusTestCase delegates to an appropriate aspect based on the > cactus.type value. Since CactusTestCase delegates to the aspect, there > is no duplicate effort in the cactus project. > > Users who are comfortable using an aspect will opt for (1). Users who > aren't will opt for (2). > > I am not clear about the usage model for (2). E.g. I currently have an > ant task for local tests, an ant task for cactus tasks, and an ant task > that runs both of these subtasks sequentially. Would I be able to retain > this setup? The ability to run all tests in a single ant task is > important. > > ----- Original Message ----- > From: "Vincent Massol" <[EMAIL PROTECTED]> > To: "'Cactus Users List'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Saturday, February 22, 2003 6:06 AM > Subject: RE: Single test class for both local and remote > > > > Hi Fed, > > > > > -----Original Message----- > > > From: Fred Loney [mailto:[EMAIL PROTECTED] > > > Sent: 05 February 2003 20:03 > > > To: Cactus Users List > > > Subject: Re: Single test class for both local and remote > > > > > > The design goal should be to execute a vanilla JUnit TestCase in a > web > > > container without a rebuild or reconfiguration. If the > > ServletTestSuite > > > in option 2b consisted of TestCase objects rather than > CactusTestCase > > > objects, that would be preferable. > > > > Yeah, except that I haven't figured out yet how it could work... (I'm > > not even sure it is possible using the JUnit framework - I'll need to > > dive into the Junit source code a bit more though to verify this). > > > > > > > > Stepping back, this problem is an ideal example of an aspect: Cactus > > > behavior is introduced at strategic cutpoints without modification > to > > > the source code. An alternative, then, is to provide a Cactus aspect > > > rather than a new Cactus class. The developer is then free to use > the > > > Cactus aspect in whatever way fits his usage model. E.g.: > > > > > > In app: > > > > > > test.local.MyTestCase extends TestCase { > > > ... // test methods > > > } > > > > > > test.web.MyServletTestCase extends MyTestCase { > > > // no test methods > > > } > > > > > > In Cactus distribution: > > > > > > aspect Cactus { > > > ... // Cactus behavior introduced into TestCase method calls > > > } > > > > > > In Ant build: > > > > > > <target name="server-testbed"> > > > <ajc ... > > > > <src> > > > <pathelement location="/tools/cactus/Cactus.ajc"/> > > > <pathelement location="${source}/test/web"/> > > > </src> > > > </ajc> > > > </target> > > > > > > This alternative enables a number of approaches for enabling Cactus > > > rather than stipulating a single mechanism. > > > > > > Note that the Cactus aspect described here is dynamic; it is not > > > equivalent to a static aspect that changes the superclass from > > TestCase > > > to ServletTestCase. > > > > > > > The idea sounds interesting but I'm not sure if I understand > correctly. > > I can see 2 issues: > > > > 1/ If the aspect is part of the Cactus source code, then we'll need to > > deliver our own junit jar as the aspect would need to be weaved > > statically into the junit code (either sources or bytecode with > AspectJ > > 1.1). Otherwise we would only be able to catch calls to JUnit, which > we > > can already do using standard java code. > > > > 2/ If the aspect is something to be used by the user, then the issue > is > > that it will complexify greatly the setup for the user who will need > to > > have AspectJ, set up his build, etc. I don't think this will be > > acceptable. > > > > Please tell me if there's something I don't understand. > > > > Thanks > > -Vincent > > > > > Fred Loney > > > > > > ----- Original Message ----- > > > From: "Vincent Massol" <[EMAIL PROTECTED]> > > > To: "'Cactus Users List'" <[EMAIL PROTECTED]> > > > Cc: <[EMAIL PROTECTED]> > > > Sent: Wednesday, February 05, 2003 1:49 AM > > > Subject: RE: Single test class for both local and remote > > > > > > > > > > Hi Fred, > > > > > > > > I have thought this morning about how to offer the "offline" > feature > > > for > > > > Cactus. I think it is possible relatively easily. Here's a > proposal > > > > below. Tell me what you think of it. If you think it will solve > your > > > > usecase, I'll make a formal proposal with more details. > > > > > > > > Proposal: > > > > > > > > * 3 ways to write a Cactus test case: > > > > 1/ MyTestClass extends ServletTestCase (or JspTestCase, etc). > This > > > is > > > > the same a now > > > > 2/ MyTestClass extends CactusTestCase, and: > > > > a/ it needs a "suite()" method such as: > > > > > > > > public static void suite() > > > > { > > > > TestSuite suite = new ServletTestSuite(); > > > > // or JspTestSuite(), etc. > > > > > > > > // For a pure Junit test > > > > // TestSuite suite = new TestSuite(); > > > > > > > > suite.add(new TestTest("testPassed")); > > > > suite.add(new TestTest("testFailed")); > > > > suite.add(new TestTest("testErrored")); > > > > return suite; > > > > } > > > > > > > > b/ there is no suite() method but the "cactus.type" system > > > parameter > > > > is passed to the JUnit Test Runner JVM. Its possible values are: > > > > "servlet", "jsp", "filter" or "none" (can also be called "junit"). > > The > > > > last one is a pure junit test. The advantage of b/ is that the > > choice > > > of > > > > offline/online is decided externally to the test case. It may make > > > sense > > > > for some cases, such as the one you mention, Fred. > > > > > > > > I won't enter in the details of the implementation but I think I > > have > > > > thought them out and it may work. > > > > > > > > What do you think? > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > -----Original Message----- > > > > > From: Fred Loney [mailto:[EMAIL PROTECTED] > > > > > Sent: 05 February 2003 07:01 > > > > > To: Cactus Users List > > > > > Subject: Re: Single test class for both local and remote > > > > > > > > > > The reason for the todo item is local/server regression testing. > > The > > > > > application framework I use insulates most of the code from the > > > > > container context. Thus, one can code and test locally quickly, > > then > > > > > occasionally deploy and test on the server using the same code > > base. > > > > > > > > > > The only hitch is that the test case must derive from > > > ServletTestCase > > > > > for server testing. The work-around I use is to pair a small > > > TestCase > > > > > with a small ServletTestCase, both of which do nothing more than > > > > > delegate to a common test exerciser object. > > > > > > > > > > It is not clear that the todo item that I initiated is > necessary, > > > > > although there might be other uses. It would be worthwhile to > keep > > > the > > > > > item open for a while. > > > > > > > > > > Fred Loney > > > > > > > > > > ----- Original Message ----- > > > > > From: "Vincent Massol" <[EMAIL PROTECTED]> > > > > > To: "'Cactus Users List'" <[EMAIL PROTECTED]> > > > > > Sent: Tuesday, February 04, 2003 12:47 AM > > > > > Subject: RE: Single test class for both local and remote > > > > > > > > > > > > > > > > Hi Tim, > > > > > > > > > > > > Yes, it may make sense in some situations. This is why we've > > added > > > a > > > > > new > > > > > > todo in the Cactus todo list > > > > > > (http://jakarta.apache.org/cactus/todo.html) about: > > > > > > > > > > > > "Ability to write Cactus tests by extending normal JUnit > > TestCase > > > > > > instead of Cactus extensions (by using special Cactus > TestSuite > > > > > > objects). This will allow to easily execute the same test > > outside > > > > and > > > > > > inside of the container (for test not depending on container > > > > objects). > > > > > > Idea suggested by <link > href="mailto:[EMAIL PROTECTED]">Fred > > > > > > Loney</link>." > > > > > > > > > > > > Now, for your problem at hand, what would be the issue about > > > running > > > > > > both the remote and local EJB class from a ServletTestCase? Is > > it > > > a > > > > > > question of speed only? > > > > > > > > > > > > Thanks > > > > > > -Vincent > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tim McNerney [mailto:[EMAIL PROTECTED] > > > > > > > Sent: 04 February 2003 01:00 > > > > > > > To: [EMAIL PROTECTED] > > > > > > > Subject: Single test class for both local and remote > > > > > > > > > > > > > > I want to build a test which works both locally (on the > client > > > > side) > > > > > > and > > > > > > > remotely (on the server side). This is basically testing the > > > local > > > > > and > > > > > > > remote interfaces of an EJB. Since much of the code would be > > the > > > > > same > > > > > > > for both, I'd like to keep it in one class. Let's say I'm > > using > > > > > > > (extending) a ServletTestCase for the server side test. Is > > there > > > > > some > > > > > > > way for me to tell my test class not to connect to the test > on > > > the > > > > > > > server side but simply run the test locally? > > > > > > > > > > > > > > And I'm making any sense? > > > > > > > > > > > > > > --Tim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
