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
