|JezUK Ltd - Unit Testing XSLT Stylesheets|
|<< Previous||November 2004||Next >>|
Here's the proposal I sent for the ACCU Conference 2005.
XSLT is now a mature technology. It's widely used in web, document composition, electronic and print publishing applications, among others. Increasingly, XSLT styling isn't the last little bit at the end to create the HTML, but at the core of document creation and processing pipelines. Indeed it isn't uncommon, particularly in publishing applications, to have multiple XSLT transformation steps chained one after the other. XSLT stylesheets are getting larger and more complex, containing significant chunks of business logic.
XSLT, while addressing the specific issue transforming XML, is Turing complete. It's a real programming language, and people are doing real work with it.
Development is easier with automated testing. It's a given. That's why Ant integrates JUnit, and why C++ programmers up and down the land spend hours developing test harnesses because CppUnit just isn't quite right.
How do you test an XSLT stylesheet?
I'd like to present a tool for XSLT testing. Tests are described in an XML vocabulary. The test definitions are cranked through a set of XSLT stylesheets to generate Java source, more XML and yet more XSLT. The Java sources are JUnit test suites which drive the XSLT test procedure. It's all stitched together with Ant.
It's all quite neat from an exposition point of view. It's an application written in more or less equal parts of Java and XSLT. It uses multiple XSLT stages. It needs testing too :) While the code I have is in Java, it can be adapted to C#, C++ or any language where you have an XSLT processor and test harness available.
I think it could make quite a snappy 45 minute session.
At lest this bloke says so - http://www.pyrasun.com/mike/mt/archives/2004/07/10/18.43.16/index.html
It's true that some things are easier to test that others. It's true the your definition of a "unit" can make a significant difference. Systems with a lot of state stashed in databases are a pain. GUIs of all sorts - web apps, Java, whatever - are also very difficult to test.
I'm doing a lot of work where significant things happen in XSLT, and so are more and more other people. Testing XSLT is a tedious, generally extremely manual, business. I'm just trying to make is a touch easier.
I think what that geezer was saying was that some of the 'thought leaders' don't give enough emphasis to the end product vs. using there methodology.
I'm not saying that unit testng isn't a good idea, and if you are programming in XSLT then being able to test it like that is a good thing. Probably more so than it is with Java as the side effects are harder to see.