Thanks for the hint about parameters. You can do that with Juxy and with UTF-X (http://utf-x.sourceforge.net/). Juxy also lets you set global variables (I think at least one of the XSLT frameworks does too). It’s not covered in the XMLUnit documentation, but inasmuch as XMLUnit just runs a JAXP transformation (and presumably does something similar for C#), setting parameters should be possible with XMLUnit, too.

I think we all have dreams of making the hub format for testing XSLT (for a very small value of “all”). I have a XML format for Juxy tests that I’ve considered could be usefully transformed into tests for other frameworks.

I guess any framework that can run a stylesheet multiple times and recover from terminating stylesheets would do the job. One issue for an XProc pipeline would be how to generate reports such that you can see the results for tests that terminated alongside results for tests that didn’t.

The Behavior-Driven-Development stuff that I’ve seen talks in the same breath about using mock objects when testing. XSLT isn’t exactly object oriented, and stylesheets seldom make any pretense of presenting an API, so in addition to being generally interested in seeing XSpec when it’s done, I’d be interested in seeing what it would say about testing XSLT.

Another good reason for going outside an XSLT-based framework is to test how stylesheet parameters should change the output.

I have a dream of having an platform-neutral XSLT test document format which could be implemented in any language. One method would be a transformation into an XProc pipeline, which you then run. XProc has the advantage of being able to set parameters, catch errors (messages), and passes on multiple result documents as one of the outputs of the XSLT step. I have no doubt that something similar could be achieved today through a transformation into an ant script.

By the way, I’ve been doing some work on a new Behavior-Driven-Development-based framework, which I have named(!) XSpec. More to come soon…

Jeni