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 Sat, 22 Feb 2003 23:45:55 GMT
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" <vmassol@octo.com>
To: "'Cactus Users List'" <cactus-user@jakarta.apache.org>
Cc: <loney@spiritedsw.com>
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:loney@spiritedsw.com]
> > 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" <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
> > >
> >
> >
>
> ---------------------------------------------------------------------
> > 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