cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: [RT] Unit testing and CocoonUnit
Date Fri, 07 Nov 2003 07:04:21 GMT
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();

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

>      WebResponse response = webConversation.getResponse(request);
> ...


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


View raw message