jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Multi Step Tests - Better HttpUnit Integration
Date Fri, 27 Sep 2002 18:24:14 GMT


> -----Original Message-----
> From: Larry Tambascio [mailto:ltambascio@charter.net]
> Sent: 26 September 2002 18:35
> To: Cactus Users List
> Subject: Re: Multi Step Tests - Better HttpUnit Integration
> 
> Steve,
> 
> See comments below.  Hope some of them help, or give you
> ideas.  Good luck!!
> 
> -Larry
> 
> 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.
> 
> Agreed.
> 
> >
> >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
> >pre-requisite
> >requests.
> 
> 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.
> 

I concur. I would add that code that needs overly complex test code to
set up usually need refactoring. This is one the code smell I always
use: if my unit test for a given method is too long, it usually means
that either my method under test is doing too many things and I need to
refactor it or that it does not obey the Law of Demeter enough (in which
case it also needs refactoring).

-Vincent



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