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?
That is an angle I had not considered -- it does provide a flexible way to test not only the end result, but also the intermediate steps of a pipeline. My only concern would be that using a different pipeline may taint the testing process as you wouldn't use the UnitTestingPipeline in a live application.
When I was first thinking about this, I was imagining testing short internal-only pipelines -- the types of pipelines that would be aggregated in other pipelines. For example, just testing the result of a FileGenerator + SQLTransformer pipeline. In contrast, testing the result of complete pipelines seems best handled by existing tools such as HTTPUnit, Cactus, or the anteater scripts that Vadim pointed out to me.
Since I'm still a few days away from actually writing pipelines for my application, it is hard for me to say which style of testing would be most useful. I plan on isolating all my logic in flow (that calls other components) and using the pipelines strictly for gathering xml and transforming it for display.
Do you feel the CocoonBean could be modified to grab the output from the short, internal only type pipelines that I described? I imagine I'd have to expose those internal pipelines to the outside somehow... perhaps your solution would be the easiest. Maybe when I reach the point where I need something I'll to cobble together a UnitTestingPipeline.
cheers, -steve
