Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3FAB471F.1020409@upaya.co.uk>
Date: Fri, 07 Nov 2003 07:17:51 +0000
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Unit testing and CocoonUnit
References: <9CE51192-10F0-11D8-9AAD-000393CFE402@apache.org>
In-Reply-To: <9CE51192-10F0-11D8-9AAD-000393CFE402@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bertrand,

Thanks for this response. I like it, and it seems to remove almost all 
of the things I dislike about this approach.

So, my comments:
1) The idea of passing an ID with the webRequest is brilliant. It gets 
around a major disadvantage. I would send the ID as a request header 
rather than as a request parameter, though.
2) I agree that the 'cocoon-unit-enable' parameter should be 'off' by 
default. That is what I was proposing, but your name is better.
3) The remaining thing I dislike is the need to have some code in the 
sitemap to accept the requests from CocoonUnit)

Thinking wildly about point 3, maybe I could write a unit test servlet 
and set it up in web.xml to answer requests to /cocoon-unit. Then you 
wouldn't need code in your sitemap. Hmm.

Thanks for this. I think I'm now close to ready to attempt implementing it.

Regards, Upayavira

Bertrand Delacretaz wrote:

> Hi Upayavira,
>
> I like the idea of reusing HTTPUnit as much as possible - here's a 
> slightly different proposal which could allow multiple simultaneous 
> unit tests.
>
>> ...
>> CocoonUnit
>> ------------
>> public class MyXMLTestCase extends XMLTestCase {
>>   public MyXMLTestCase(String name) {
>>       super(name);
>>   }
>>   public void testForEquality() throws Exception {
>>      CocoonUnit cocoon = new 
>> CocoonUnit("http://localhost:8080/unit-manager");
>
>
> Now putting this the other way round so that the WebRequest can pass a 
> test context ID, and using a setup object instead of multiple option 
> calls on CocoonUnit:
>
>       CocoonUnitContext ctx = new CocoonUnitContext();
>       ctx.setCollectStageXML(1);
>       ctx.setCollectStageXML(2);
>
>       // here the cocoon server allocates an internal test context, 
> returns its ID
>       final String testContextId = cocoon.prepareTest(ctx);
>
>>      WebConversation webConversation =  new WebConversation();
>>      WebRequest request = new 
>> GetMethodWebRequest("/samples/hello-world/hello.html");
>
>
>       // test ID must be passed to server, can be reused several times
>       // for stress testing, as long as only one request with this 
> particular ID is
>       // active a a given time
>       request.setParameter("cocoon-unit-id",testContextId);
>
>>      WebResponse response = webConversation.getResponse(request);
>> ...
>
>
> etc...
>
>> ...
>> Cocoon Servlet Changes
>> ---------------------
>> The cocoon servlet is extended with a single extra init parameter 
>> "test" which is set to either 'on' or 'off'. (This could equally be 
>> in cocoon.xconf).
>
>
> IMO, for security reasons, this must be accepted only if a 
> configurable "cocoon-unit-enable" parameter is set to on, and it must 
> be set to off by default.
>
>> When the cocoon.informServer() method is called, an HTTP post is sent 
>> to the server, encapsulating details of the stages for which XML must 
>> be gathered....
>
>
> In the above scenario, this must return a test ID string.
>
>> ...When the webConversation.getResponse() is called, the server, if 
>> the test input parameter is set to on, looks to see if this object is 
>> present in the persistent store....
>
>
> This would then use the test ID string.
>
>> ...The only downside of this as I currently see it is that only one 
>> person must be testing a site at any one time, as they cannot share 
>> their transient store objects.
>
>
> That's a big downside as IIUC it would prevent one from stress-testing 
> a pipeline using multiple client threads or hosts.
>
> But of course, if allowing multiple simultaneous unit tests 
> complicates your implementation too much, feel free to ignore this!
>
> -Bertrand
>
>