cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: Unit testing pipelines?
Date Mon, 29 Sep 2003 05:54:38 GMT
Steve K wrote:

> Hello everyone --
>
> I am currently building a Cocoon application and so far I've extended 
> the ExcaliburTestCase class to write my JUnit tests for the components 
> I'm creating.  However, I'm now at the point where I am starting to 
> write pipelines that generate XML based on the database manipulations 
> the previously mentioned components perform, and it appears that there 
> is no easy way to test these.  For example, my ideal test code might 
> look like:
>
> myCustomComponent.doSomething();
> Document actualXml = cocoon.process("/path/to/my/pipeline");
> Diff diff = new Diff(actualXml, expectedXml);
> assertTrue("pipeline test", diff.identical());
>
> I suppose I could use something like HTTPUnit here, and set up a test 
> script to start cocoon, request the uri and parse the result into 
> XML...  but that seems a little messier than it should be.
>
> I've looked at the CocoonBean stuff, and while it is close, it seems 
> geared toward publishing pages rather than embedding cocoon and 
> directly calling pipelines.
>
> Does this sound like a good idea, or is everyone just using HTTPUnit 
> for this level of testing?  Might it be possible to modify CocoonBean 
> to allow direct access to the result of calling a pipeline?  Does 
> anyone think unit testing pipelines this way is actually valuable?

Steve,

The bean is intended to be a programmatic interface to Cocoon, not just 
for publishing. There is a method (I'm not sure how well it works 
though, but I can check), to write the contents of a pipeline to an 
output stream, which is closer to what you are talking about.

You could do what you're talking about by implementing a 
UnitTestingPipeline, to replace the default CachingProcessingPipeline.

So what you'd do is, in the Bean, pass in a set of 'expected' XMLs'. for 
each stage of the pipeline. The Bean puts these details into the 
environment, available for the pipeline. When generating a page, the 
UnitTestingPipeline, as well as passing the content of the stage on to 
the next stage, takes a copy and compares it to the relevant 'expected 
XML' for that stage. If you look at AbstractCachingPointPipeline, I 
think you'll see a pipeline that more or less does this, in order to 
cache the content. You could replace that with code to test the XML.

So, a UnitTestingPipeline in combination with extensions to the CLI/Bean 
to be able to configure this pipeline, wouldn't be too hard to 
implement. Are you interested?

Regards, Upayavira



Mime
View raw message