> -----Original Message-----
> From: Larry Tambascio [mailto:[EMAIL PROTECTED]]
> 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
