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 Vishal Batra <vi...@adeptia.com> on 2003/02/07 10:30:37 UTC
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
>
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