----- Original Message -----
From: "Russell Gold" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2001 5:18 PM
Subject: Re: [cactus]A Heath Robinson lash up with HttpUnit
> At first glance, I see two ways to accomplish this:
>
> 1) The "arms length" approach.
>
> I need to refactor HttpWebResponse and WebResponse to allow subclasses to
> supply an input stream and (initial) set of headers. This is on my todo
> list to support <meta> tags in servletunit clients. Once this is done, it
> will be easy to create a CactusWebResponse to extend WebResponse.
>
> It might then be desirable to let clients define their endXXX method to
> take either a WebResponse or an HttpURLConnection. Implementations which
> chose the former interface would receive the CactusWebResponse.
>
> 2) The "tight integration" approach.
>
> It would be possible along these lines to have Cactus use WebConversation
> as its HTTP client. This impacts many more classes, so would be a lot more
> work. The potential advantage would be the ability to chain tests, using
> the results from one request to create the next request. It is not clear
to
> me whether this is worth the effort, as Cactus does not seem to preserve
> server state between calls, so chaining could be more confusing to users
> than helpful.
>
Regarding chaining, I absolutely do not wish to preserve any state as in my
opinion any tests _must_ be independent of another. These are _unit_ test. I
agree that for functional and acceptance tests it is useful but not for unit
tests where it is very dangerous (side effects) and breaks the model.
> I could accomplish at least most of (1) fairly soon, I think.
>
I like option 1 :-)
Thanks for your help.
>
> BTW, who is "Heath Robinson"?
>
-Vincent
