jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry Tambascio" <ltambas...@charter.net>
Subject Re: Multi Step Tests - Better HttpUnit Integration
Date Thu, 26 Sep 2002 17:34:51 GMT

See comments below.  Hope some of them help, or give you 
ideas.  Good luck!!


On Thu, 26 Sep 2002 12:07:18 -0400
  "Steve Appling" <steve100@appling.org> wrote:
>What Cactus buys me is the ability to have a test running 
>in the container
>with an instance of my servlet.  After all of the setup 
>(which is what I am
>using HttpUnit for) I can make asserts about the internal 
>state of my
>Servlet.  I don't have a way of doing this by just 
>looking at the servlet's
>response with HttpUnit.


>It may be possible to preset the state of my system 
>before this one call,
>but it would be extremely complicated.  The particular 
>servlets under test
>rely on other parts of the web application being set up. 

Wouldn't those be setup within the container on startup?

> Some of those
>parts are outside of my control and do not have a 
>convenient mechanism to
>initialize them to a particular state.  It seems that the 
>most reliable way
>of running my test in the actual context that the code 
>will execute under
>when in production is to actually generate the required 

Until one of those other parts changes or breaks, and then 
your test fails.  What you're doing is fantastic 
integration or functional testing.  It's not unit testing 
your servlet.  (Oh, I hope I didn't open the "what is unit 
testing vs. functional testing" can of worms/debate.)

It actually sounds like we're in similar boats, Steve.  My 
project has complicated setup.  The only way to 
instantiate the controller servlet is through the web-app 
container (Tomcat in my case).  When I focused on what I 
minimally needed to test my piece of code, I found that 
there really wasn't as much needed for setup as I had 
feared.  I instantiate my operations/actions and required 
beans in the setUp or testXxx methods, and then 
specifically invoke them.

I'm sure there are more differences than similarities, 
however, between our situations.  Perhaps some testing 
helper classes could facilitate environment setup??  What 
about those preliminary servlets??  Do you have tests for 
them??  It seems like there should be a starting servlet 
that simply needs the container/application up and running 
(and little else beyond maybe user login info).  Start 
with that.  Get a test case for that servlet that 
initializes the environment, and then move on to the next. 
 You are running your Cactus servlet redirector in the 
same container as your application, right?  Then it should 
have everything that all the other servlets have available 
to them.

I don't mean to oversimplify or minimize your plight, but 
manually setting up the environment can be messy, 
especially if alot is needed.  Your HttpUnit solution 
could well be the simplest way of setting up the context. 
 That doesn't necessarily make it the best.

Sorry I couldn't be of more help.

>----- Original Message -----
>From: "Larry Tambascio" <ltambascio@charter.net>
>To: "Cactus Users List" <cactus-user@jakarta.apache.org>
>Sent: Thursday, September 26, 2002 11:48 AM
>Subject: Re: Multi Step Tests - Better HttpUnit 
>> Hi Steve,
>> It sounds to me like what you really need is HttpUnit.
>>  I'm unsure what Cactus is buying you.  What I have
>> usually done is to setup the session as though all your
>> preceding requests and responses have been made.  My 
>> is that it would take about the same amount of code to
>> setup all the session values as it does to do the 
>> web conversation thing.  Finding out what those all are
>> could be tedious, but it would make your tests cleaner 
>> faster, IMHO.
>> -Larry
>To unsubscribe, e-mail: 
>  <mailto:cactus-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 

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

View raw message