> Upayavira wrote:
I think the bit that Vadim didn't perhaps mention is that you could use something like HTTPUnit with cocoon views, thus getting at the content at a certain point in a pipeline. You could even build views that have transformations to simplify this XML, so that when you get XML out of your view, you can do an identity comparision with your expected XML.
That is a good use of the view, however I have this strong desire to have the testing of pipelines more integrated with my JUnit tests. I like being able to click the "run" button on Eclipse and watch the little green bar move across the screen without having to worry about starting up cocoon, etc. Also, my tests would be more like "do x with component a, and check the results of pipeline y" which would require putting test code within cocoon if I wanted to use anteater, etc.
The challenge would be how to link a particular XML that has been 'intercepted' within a pipeline with an expected XML. How do you 'annotate' a pipeline to identify what XMLs you're expecting?
Hm... how about a custom pass-through transformer that will validate the xml against a document in the environment referenced by some id? something like:
What I was talking about was doing something like that transparently - i.e. so you don't need to make changes in your sitemap.
<map:generate src="sql.xml"/> <map:transform type="sql"/> <map:transform type="xmlunit"> <map:parameter name="expected-xml-id" value="sqlresult"/> </map:transform> ...
The "sqlresult" document would be placed in the environment by the test before the pipeline is called. And perhaps the xmlunit transformer could be part of a view made for testing.
That sounds sensible. Have the Bean add a 'something' to the ObjectModel, which is then used by the UnitTransformer, which you've placed into a view. The UnitTransformer then uses this object in some way to evaluate whether or not the XML is valid. Then you can pass back the result to the caller, either as XML, or using a text serializer.
This would be much simpler than a UnitTestingPipeline, but would have the downside that each stage you test in a pipeline would require a page to be generated, whereas with a UnitTestingPipeline, you could test all stages in the pipeline in one go, but it would be much harder to configure.
This might be easier than the custom pipeline processor, but I'm still not happy with putting test stuff in cocoon itself.
"Putting test stuff in cocoon itself"? What do you mean?
Regards, Upayavira
