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




Reply via email to