> Yes, but if it's the same test, why do you need to run it on the server? If > it doesn't use server resources, why do you need to run with those resources > present?
The app framework I use determines whether the app uses local or server resources, independent of the class source code. Therefore it would be desirable if a given test class could use local or server resources, independent of the test class source code. Although the code doesn't change, the execution path takes an entirely different course, depending on whether it runs locally or in a container. Therefore, it is desirable to run the same test in both contexts. If a developer uses an app framework that insulates the app model from the execution context, then a single test class would be useful. If a developer does not use such a framework, then it would not be useful. An app server is a mechanism for pushing data around. 80% of the app Java code should have nothing to do with the details of this mechanism. Therefore 80% of the app should operate as easily outside a container as inside the container. The framework I use provides this capability. For most developers, the container mechanism infiltrates every aspect of the application. For those developers, a single test case is not relevant. Fred Loney Spirited Software, Inc. www.spiritedsw.com ----- Original Message ----- From: "Nicholas Lesiecki" <[EMAIL PROTECTED]> To: "Fred Loney" <[EMAIL PROTECTED]> Sent: Thursday, February 06, 2003 1:03 PM Subject: RE: Single test class for both local and remote > Yes, but if it's the same test, why do you need to run it on the server? If > it doesn't use server resources, why do you need to run with those resources > present? > > That's what I don't get. > > Cheers, > nick > > > -----Original Message----- > > From: Fred Loney [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, February 06, 2003 2:08 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Single test class for both local and remote > > > > > > The rationale is explained in the quoted post: > > > > > > > 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. > > > > "same code base" means the same JUnit TestCase used locally. > > > > Fred Loney > > > > ----- Original Message ----- > > From: "Nicholas Lesiecki" <[EMAIL PROTECTED]> > > To: "Cactus Users List" <[EMAIL PROTECTED]> > > Sent: Thursday, February 06, 2003 8:01 AM > > 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. > > > > > > Could you explain more about the rationale behind this? Why is it > > better to > > > use a vanilla test case than a Cactus one? I think I see where you're > > going, > > > but I want to understand a little better. > > > > > > I'm not sure an aspect is necessary for this. It depends on the > > > requirements. > > > > > > Cheers, > > > Nick > > > > > > > -----Original Message----- > > > > From: Fred Loney [mailto:[EMAIL PROTECTED]] > > > > Sent: Wednesday, February 05, 2003 12:03 PM > > > > 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. > > > > > > > > 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. > > > > > > > > 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]
