jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robertson, Jason" <Jason.Robert...@acs-inc.com>
Subject RE: [Musing] Offline mode
Date Wed, 20 Nov 2002 18:34:41 GMT
Sorry to take so long to respond, but I'm not clear as to the full benefits
of doing this. If I'm creating a servlet, and that servlet does nothing
involving certain container resources (i.e., connection pools, EJBs, etc.),
then I could see how a "mock" container could work. But how often does this
happen?

And I don't see at all how it could test JSPs (would the mock container
compile them into servlets?), or EJBs. 

The far majority of my cactus testing is testing EJBs, and will soon be
testing Struts action classes which will all use EJBs to get their data. Am
I just not a potential "offline mode" user, and that's why I can't see it?
Am I missing the big picture?

Jason 

-----Original Message-----
From: Vincent Massol [mailto:vmassol@octo.com]
Sent: Saturday, November 02, 2002 12:00 PM
To: 'Cactus Users List'
Cc: cactus-dev@jakarta.apache.org
Subject: [Musing] Offline mode


Hi Cactusers,

Today I haven been thinking about Cactus and Mock Objects and more
specifically when to choose one over another, etc. The choice is not
always easy. In the past, I had thought about implementing an offline
mode in Cactus, i.e. the ability to run the same cactus test without a
container. Of course, it won't be integration unit testing any more but
the rationale is the following:

* use the offline mode when coding in your favorite IDE. Run the tests
very often.
* use the online mode to perform integration unit testing with your
target containers.
* The benefits over using an existing mock object library for
Servlet/JSP/Filter/EJBs API is evident: tests written using the Cactus
API can run "as is" in in-container mode.

Of course, not all tests should be run in both modes but a lot of them
could.

At that time I had dismissed the idea because I did not see how I could
do it and I did not see the real interest of doing so. It seems much
clearer now... :-)

Here are some ideas:

* The mode is specified by passing a JVM system parameter
(-Dcactus.offline=true)
* In offline mode, Cactus creates dummy (mock) Servlet implicit objects,
and filling them with the information it has (mostly from WebRequest).
* In addition, the wrappers need to be extended (or added) to offer
methods to set the behaviours of the mocks. For example:
HttpServletRequestWrapper.setForwardResult(HttpServletResponse response,
OutputStream mockStream)
* In online mode, the setForwardResult() and such can be ignored.
However, if we want to refine this, we can also have an additional
HttpServletRequestWrapper.setForwardResult(HttpServletResponse response,
OutputStream mockStream, boolean useInOnlineMode) API that tells Cactus
to use this even in online mode. This can be handy when the JSP is not
yet written and you still wish to perform integration unit tests.
* In offline mode, there is no HTTP connection to the server side and
beginXXX(), testXXX() and endXXX() are all run on the client side.

What do you think?

-Vincent


--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>


Mime
View raw message