Upayavira wrote:
"Putting test stuff in cocoon itself"? What do you mean?

In my experience writing tests, generally you regard the thing you are testing as a "black box" -- the thing being tested should have no knowledge that it is being tested rather than running in a production environment. For example, the ExaclburTestCase is used to set up an Avlon environment for you to test Avalon components without changing them. I feel that adding "unittest" transformers to the sitemap or using a custom pipeline processor violates this principle. However, I am not overly religious about this -- if there already was a UnitTestPipeline and the appropriate hooks into the CocoonBean I would probably use it.


It seems to me that the closest thing to what I really want would be the processURI() method in CocoonWrapper. Assuming this could be instantiated and called from a JUnit test, it would give me the black box effect I'm looking for. Ideally I'd like to be able to call any pipeline (including internal-only ones) and get back the result XML rather than the serialized form. I am not very familiar with the internals of Cocoon, but I suspect this would not be an easy thing to do. So we're probably back to a custom pipeline processor that can gather the XML from each step of the pipeline and return it in the environment somewhere (where would that be?).

It also might be possible to host the Cocoon component in the EcaliburTestCase environment -- but I'm not sure if this gets me any closer to the internal-only pipelines and XML as I'm still at the mercy of the process() method.

cheers,
-steve



Reply via email to