[Musing] Offline mode

[Vincent Massol <vm...@octo.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Musing] Offline mode

[Christopher Lenz <cm...@gmx.de>]

Hi Vincent,

I love this idea! It's so simple, but looks very useful and effective :-)

See below for comments...

Vincent Massol wrote:
> 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.

The tests that could not be run would be functional, HttpUnit based 
tests, right? And of course tests that require the JNDI context etc.

> 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)

How about assuming offline mode when the contextURL parameter is not 
present?

> * In offline mode, Cactus creates dummy (mock) Servlet implicit objects,
> and filling them with the information it has (mostly from WebRequest).

Would those be simple dummy implementations or real mocks, for example 
based on the mockobjects.com stuff? I think dummies should be 
sufficient, and would rather avoid the term "Mock" in that context.

> * 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.

Yeah, for example Cactus-based StrutsTestCase test-cases can take a long 
time to complete, because (I believe) Struts still forwards to a JSP, 
and often that JSP needs be compiled first. While it's sometimes handy 
to get notified about syntax errors in the JSP this way, it's really not 
the concern of the unit test ;-)

> * 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

-- 
Christopher Lenz
/=/ cmlenz at gmx.de


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>