You are viewing a plain text version of this content. The canonical link for it is here.

Posted to cactus-user@jakarta.apache.org by Tim McNerney <mc...@navis.com> on 2003/02/04 01:00:19 UTC

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

Re: Single test class for both local and remote

Posted by Fred Loney <lo...@spiritedsw.com>.

There might be some confusion about terminology. The EJB local/remote
distinction is orthogonal to the cactus client/server distinction. A
test case is always an EJB client. On the other hand, the test code will
necessarily differ depending on whether the local or remote EJB is
called. Thus the test code must differ but it is always an EJB client.
The question seems to imply that the test code is the same but it need
not always be an EJB client.

Fred Loney

----- Original Message -----
From: "Tim McNerney" <mc...@navis.com>
To: <ca...@jakarta.apache.org>
Sent: Monday, February 03, 2003 4:00 PM
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
>
>

RE: HtmlUnit Integration

Posted by Vincent Massol <vm...@octo.com>.

Hi Vishal,

Cactus does not provide any integration with HtmlUnit. However, we're
open to suggestions and we love patches! :-)

Thanks
-Vincent

Note: Unfortunately, I don't know HtmlUnit myself so I'm unable to
comment on the easiness of a Cactus/HtmlUnit integration. Maybe someone
else knows?

> -----Original Message-----
> From: Vishal Batra [mailto:vishal.batra@adeptia.com]
> Sent: 07 February 2003 10:31
> To: Cactus Users List
> Subject: HtmlUnit Integration
> 
> Hi,
> 
> The documentation provided with Cactus explains about how to integrate
> HttpUnit with Cactus.
> 
> I was more intrested in integrating HtmlUnit with cactus...Any
> suggestions??
> 
> Thanx,
> 
> Vishal
> 
> ----- Original Message -----
> From: "Nicholas Lesiecki" <ni...@eblox.com>
> To: "Cactus Users List" <ca...@jakarta.apache.org>
> Sent: Thursday, February 06, 2003 9:31 PM
> 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:loney@spiritedsw.com]
> > > 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" <vm...@octo.com>
> > > To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> > > Cc: <lo...@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" <vm...@octo.com>
> > > > > To: "'Cactus Users List'" <ca...@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
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org

HtmlUnit Integration

Posted by Vishal Batra <vi...@adeptia.com>.

Hi,

The documentation provided with Cactus explains about how to integrate
HttpUnit with Cactus.

I was more intrested in integrating HtmlUnit with cactus...Any suggestions??

Thanx,

Vishal

----- Original Message -----
From: "Nicholas Lesiecki" <ni...@eblox.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Thursday, February 06, 2003 9:31 PM
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:loney@spiritedsw.com]
> > 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" <vm...@octo.com>
> > To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> > Cc: <lo...@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" <vm...@octo.com>
> > > > To: "'Cactus Users List'" <ca...@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
>

RE: Single test class for both local and remote

Posted by Nicholas Lesiecki <ni...@eblox.com>.

> 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:loney@spiritedsw.com]
> 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" <vm...@octo.com>
> To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> Cc: <lo...@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" <vm...@octo.com>
> > > To: "'Cactus Users List'" <ca...@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
>
>

RE: Single test class for both local and remote

Posted by Vincent Massol <vm...@octo.com>.

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:loney@spiritedsw.com]
> 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" <vm...@octo.com>
> To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> Cc: <lo...@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" <vm...@octo.com>
> > > To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> > > Cc: <lo...@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" <vm...@octo.com>
> > > > > To: "'Cactus Users List'" <ca...@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
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org

RE: Single test class for both local and remote

Posted by Vincent Massol <vm...@octo.com>.


> -----Original Message-----
> From: Fred Loney [mailto:loney@spiritedsw.com]
> Sent: 24 February 2003 18:18
> To: Cactus Users List
> Subject: Re: Single test class for both local and remote
> 
> Good solution, Vincent! Easy and effective.
> 
> Is it possible to include a different test case in the suite? E.g.
> 
> LocalTest.java:
> public class LocalTest extends TestCase {
>    // standard JUnit test case
> }
> 
> ContainerTest.java:
>  public class ContainerTest extends TestCase {
>       public static Test suite() {
>           ServletTestSuite suite = new ServletTestSuite();
>           suite.addTestSuite(LocalTest.class);
>           return suite;
>       }
> }

Yes! This is completely transparent for Cactus :-). I have uploaded a
dev build on
http://cvs.apache.org/builds/jakarta-cactus/nightly/2003-02-24/ if you
want to try it out.

[snip]

-Vincent

Re: Single test class for both local and remote

Posted by Fred Loney <lo...@spiritedsw.com>.

Good solution, Vincent! Easy and effective.

Is it possible to include a different test case in the suite? E.g.

LocalTest.java:
public class LocalTest extends TestCase {
   // standard JUnit test case
}

ContainerTest.java:
 public class ContainerTest extends TestCase {
      public static Test suite() {
          ServletTestSuite suite = new ServletTestSuite();
          suite.addTestSuite(LocalTest.class);
          return suite;
      }
}

Fred Loney

----- Original Message -----
From: "Vincent Massol" <vm...@octo.com>
To: "'Cactus Users List'" <ca...@jakarta.apache.org>
Cc: <lo...@spiritedsw.com>
Sent: Sunday, February 23, 2003 10:08 AM
Subject: RE: Single test class for both local and remote


> Done! It is now possible to run pure JUnit tests on the server side
> using Cactus :-)
>
> Here is an example:
>
>   public class TestJUnitTestCaseWrapper extends TestCase
>   {
>       public TestJUnitTestCaseWrapper(String theName)
>       {
>           super(theName);
>       }
>
>       public static Test suite()
>       {
>           ServletTestSuite suite = new ServletTestSuite();
>           suite.addTestSuite(TestJUnitTestCaseWrapper.class);
>           return suite;
>       }
>
>       public void testXXX()
>       {
>       }
>   }
>
> Hope you like it (it took me a good part of the afternoon! :-)).
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Fred Loney [mailto:loney@spiritedsw.com]
> > 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" <vm...@octo.com>
> > To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> > Cc: <lo...@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" <vm...@octo.com>
> > > > To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> > > > Cc: <lo...@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" <vm...@octo.com>
> > > > > > To: "'Cactus Users List'" <ca...@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
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> > 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
>
>

RE: Single test class for both local and remote

Posted by Vincent Massol <vm...@octo.com>.

Done! It is now possible to run pure JUnit tests on the server side
using Cactus :-)

Here is an example:

  public class TestJUnitTestCaseWrapper extends TestCase
  {
      public TestJUnitTestCaseWrapper(String theName)
      {
          super(theName);
      }

      public static Test suite()
      {
          ServletTestSuite suite = new ServletTestSuite();
          suite.addTestSuite(TestJUnitTestCaseWrapper.class);
          return suite;
      }
 
      public void testXXX()
      {
      }
  }

Hope you like it (it took me a good part of the afternoon! :-)).

Thanks
-Vincent

> -----Original Message-----
> From: Fred Loney [mailto:loney@spiritedsw.com]
> 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" <vm...@octo.com>
> To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> Cc: <lo...@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" <vm...@octo.com>
> > > To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> > > Cc: <lo...@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" <vm...@octo.com>
> > > > > To: "'Cactus Users List'" <ca...@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
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org

Re: Single test class for both local and remote

Posted by Fred Loney <lo...@spiritedsw.com>.

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" <vm...@octo.com>
To: "'Cactus Users List'" <ca...@jakarta.apache.org>
Cc: <lo...@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" <vm...@octo.com>
> > To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> > Cc: <lo...@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" <vm...@octo.com>
> > > > To: "'Cactus Users List'" <ca...@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
>
>

RE: Single test class for both local and remote

Posted by Vincent Massol <vm...@octo.com>.

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" <vm...@octo.com>
> To: "'Cactus Users List'" <ca...@jakarta.apache.org>
> Cc: <lo...@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" <vm...@octo.com>
> > > To: "'Cactus Users List'" <ca...@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

Re: Single test class for both local and remote

Posted by Fred Loney <lo...@spiritedsw.com>.

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" <vm...@octo.com>
To: "'Cactus Users List'" <ca...@jakarta.apache.org>
Cc: <lo...@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" <vm...@octo.com>
> > To: "'Cactus Users List'" <ca...@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
>

RE: Single test class for both local and remote

Posted by Vincent Massol <vm...@octo.com>.

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" <vm...@octo.com>
> To: "'Cactus Users List'" <ca...@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

Re: Single test class for both local and remote

Posted by Fred Loney <lo...@spiritedsw.com>.

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" <vm...@octo.com>
To: "'Cactus Users List'" <ca...@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
>
>

RE: Single test class for both local and remote

Posted by Vincent Massol <vm...@octo.com>.

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

RE: Single test class for both local and remote

Posted by Nicholas Lesiecki <ni...@eblox.com>.

Tim,

You could implement a common method that did your testing, and then call it
from both beginXXX (client-side) and testXXX (server-side). Would that work
for you?

Cheers,
Nick

P.S. You could also control whether a class extended TestCase or
ServletTestCase at compile time using AspectJ. See:

http://www-106.ibm.com/developerworks/java/library/j-aspectj2/?loc=j

Cheers,
Nicholas Lesiecki
Principal Software Engineer
eBlox, Inc.
> -----Original Message-----
> From: Tim McNerney [mailto:mcnerney@navis.com]
> Sent: Monday, February 03, 2003 5:00 PM
> 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
>