jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fred Loney" <lo...@spiritedsw.com>
Subject Re: Single test class for both local and remote
Date Wed, 05 Feb 2003 19:02:55 GMT
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" <vmassol@octo.com>
To: "'Cactus Users List'" <cactus-user@jakarta.apache.org>
Cc: <loney@spiritedsw.com>
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:loney@spiritedsw.com]
> > 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" <vmassol@octo.com>
> > To: "'Cactus Users List'" <cactus-user@jakarta.apache.org>
> > 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:loney@spiritedsw.com">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:mcnerney@navis.com]
> > > > Sent: 04 February 2003 01:00
> > > > To: cactus-user@jakarta.apache.org
> > > > 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:
cactus-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> cactus-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
cactus-user-help@jakarta.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
>


Mime
View raw message