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 21:17:52 GMT
I understand all the points you make as far as in- vs. out-of-container, and
I'm with ya on that part - Cactus tests are slow! :)

But, what I don't see is, to pick one specific example, is how would I test
my EJBs? Or even how would I test my struts action classes? In both of these
cases I have to validate data that was retrieved from the database, external
systems, etc. And in my probably narrow view of the world, it seems like any
dynamic web-app would do something similar, and that most tests validate
that data was retrieved successfully and put into the request/session/etc.
appropriately. If I don't design mock objects to simulate the retrieval of
the data (which it doesn't sound like I would do in your description) how
does this happen? What am I validating?

Again, maybe I'm just not the right customer, because you speak of finding
errors not related to integration and I'm not seeing a clear example of what
kind of errors you'd be finding.

Jason

-----Original Message-----
From: Vincent Massol [mailto:vmassol@octo.com]
Sent: Wednesday, November 20, 2002 3:16 PM
To: 'Cactus Users List'
Subject: RE: [Musing] Offline mode


Hi Jason,

The idea is simply productivity boost. Running a Cactus test takes time
whereas a mock one is fast. You can run around 400 mock objects tests in
a second whereas Cactus tests will take at least 10-20 seconds overall
(or more. That's best time). Cactus tests yields more value as they
really verify that it works. But MO tests are enough to find errors not
related to integration. Both are good and complementary.

The idea is to have the best of both worlds by writing only one test (if
possible, not sure yet how well this would be). That is you would run
the tests quickly from your IDE as you type and from time to time you
would run with online mode on to verify it does really work.

In practice I am using both MO and Cactus on my projects but I have to
write against 2 frameworks.

Does it make sense?

Thanks
-Vincent

> -----Original Message-----
> From: Robertson, Jason [mailto:Jason.Robertson@acs-inc.com]
> Sent: 20 November 2002 18:35
> To: 'Cactus Users List'
> Subject: RE: [Musing] Offline mode
> 
> 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>



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