Future development is happening on the Trac and Subversion for the xslide SourceForge project.  See https://sourceforge.net/apps/trac/xslide/wiki/WikiStart.

Where this becomes useful (outside of your own Java programs) is being able to specify the initial template and/or mode in the <xslt> task in Ant build files. Previously, if you needed to specify either, you could only run the net.sf.saxon.Transform class with the <java> task and provide command line arguments or, when processing multiple files at once, both run Java as an external program using the <apply> task and handle the dependencies yourself.

So the good, and more readable, news is that this:

<target name="new.build"
        description="Make a build file for a translation.">
  <exec executable="java"
        dir="${basedir}"
        output="build.xml">
    <arg value="-cp" />
    <arg file="${saxon.jar}" />
    <arg value="net.sf.saxon.Transform" />
    <arg value="-xsl:${xsl.dir}/build.xsl" />
    <arg value="-it:build" />
    <arg value="build.properties=${basedir.converted}/build.properties"/>
  </exec>
</target>

can, with extra dependency checking added, become:

<target name="new.build"
        description="Make a build file for a translation.">
  <dependset>
    <srcfileset file="${xsl.dir}/build.xsl" />
    <srcfileset file="${basedir.converted}/build.properties" />
    <targetfileset file="${basedir}/build.xml" />
  </dependset>
  <xslt in="${xsl.dir}/build.xsl"
        out="${basedir}/build.xml"
        style="${xsl.dir}/build.xsl"
        classpath="${saxon.jar}">
    <factory name="net.sf.saxon.TransformerFactoryImpl">
      <attribute
          name="http://saxon.sf.net/feature/initialTemplate"
          value="build"/>
    </factory>
    <param name="build.properties"
           expression="${basedir.converted}/build.properties"/>
  </xslt>
</target>

But I’m still stumped over whether it’s possible (without resorting to either scripting or using <apply> to run another Ant) to use <xslt> with an initial template over a range of non-XML files where, for each in turn, the filename is passed to the transform as a parameter, i.e., to rework this to use <xslt>:

<target name="lines">
  <dependset>
    <srcfileset file="${books}" />
    <srcfileset file="${xsl.dir}/lines.xsl" />
    <targetfileset dir="${stages.dir}/${stage.lines}"
                   includes="*.tstamp" />
  </dependset>

  <echo>Stage 0: lines</echo>
  <mkdir dir="${stages.dir}/${stage.lines}" />
  <apply executable="java"
         dir="${stages.dir}/${stage.lines}"
         logerror="true">
    <arg value="-cp" />
    <arg file="${saxon.jar}" />
    <arg value="net.sf.saxon.Transform" />
    <arg value="-ext:on" />
    <arg value="-xsl:${xsl.dir}/lines.xsl" />
    <arg value="-it:doc" />
    <arg value="books=file://${books}"/>
    <arg value="encoding=${encoding}"/>
    <srcfile prefix="doc="/>
    <fileset dir="${basedir.converted}/sources"
             includes="*${suffix}"/>
    <mapper type="glob"
            from="*${suffix}"
            to="${stages.dir}/${stage.lines}/*.tstamp"/>
    <redirector>
      <!-- redirect STDOUT to make timestamp file in dest-dir -->
      <outputmapper type="glob"
                    from="*${suffix}"
                    to="${stages.dir}/${stage.lines}/*.tstamp"/>
    </redirector>
  </apply>
</target>

Bundled Ant means (almost) no extra downloads, and the recently added ${ps} editor variable for the path separator for the current platform means that a single “External Tool” definition works for both Linux and Windows (where previously I needed two definitions that differed only in using “:” or “;”). Continuing with the trick of using <oXygen/> editor variable names in the Ant build file, the command line  that I use (with line breaks added for clarity) is:

java -Dant.home="${oxygenInstallDir}/tools/ant"
-cp "${oxygenInstallDir}/tools/ant/lib/ant-launcher.jar"${ps}
"${oxygenInstallDir}/tools/ant/lib/ant.jar"${ps}
"${oxygenInstallDir}/tools/ant/lib/ant-trax.jar"${ps}
"${oxygenInstallDir}/lib/saxon9ee.jar"${ps}
"${oxygenInstallDir}/lib/saxon9-ant.jar"
org.apache.tools.ant.launch.Launcher
-f ${pd}/tests/build-xspec.xml -Dpd=${pd} -Din=${cfne} run

The only extra download is saxon9-ant.jar, which I added to my <oXygen/> installation so I could use a Saxon-specific Ant task. You can still run Ant, but not the Saxon Ant task, from <oXygen/> if you don’t have it, and it may yet come with a future release.

The XSL FO 2.0 talk covers: a quick overview of XSL 1.1 (by building up a formatted page in the manner of Genesis 1); the current uses for XSL; the W3C XSL FO subgroup; the XSL 2.0 requirements workshop and requirements document; and some examples of what will be possible with XSL 2.0.

The “Testing XSLT” talk from XML Prague 2009 covers more of the “what” and “why” of testing XSLT that previous renditions of the talk or tutorial. It consequently has fewer details about individual tools, but for that there’s now resource pages for XSLT and XSL FO tools on the Menteith Consulting website.

The other XML Prague 2009 talk is about Xcruciate, where I was the second speaker with Mark Howe of Cyberporte, and the posters were about XSL FO 2.0 requirements and using XSLT with xmlroff to generate C source code and other things.

Particularly when you are writing tests after someone else wrote the stylesheet, if you find yourself on a roll with all your new tests coming up green first time, it can be useful to occasionally break a working test a little so that it’s bound to fail. If the test fails, then you’ve confirmed what you already knew, and you can fix the test and move on.  If the test doesn’t fail, that’s useful information, too, since you’ve shown there’s a mistake in the tests or the stylesheet.

It doesn’t really matter how you break the test, provided that it really is broken and that you can change it back easily.  Little ways of breaking a test include: adding a character to element or attribute names, either in XPaths in assertions or in expected results; deleting an element or attribute in expected results; or adding a character or two to expected text or attribute values.

I recently added tests to a stylesheet and tests written by a client.  I did purposely break a working test from time-to-time to check that things were as I expected (and from time-to-time accidentally break a test on the way to getting a working test).  However, a few of the tests that I’d received were written with assertions that would never fail, and these had to be rewritten.  Happily, the section of the stylesheet that they covered was correct, which goes to show that some days you may be the best XSLT exponent on the planet and other days you may make a simple mistake and not realise it.

I’ve been riding my hobby horse for a while about the usefulness, nay necessity, of using more than XSLT when testing XSLT (and I’ll be back in that saddle again at XML Prague). Juxy fits that bill, since it’s in Java, but it always seems to me that writing tests in Java is more than many XSLT practitioners would want to do. So I wrote a stylesheet to generate Java from XML descriptions of the tests.

Here’s a Java test case from the Juxy project page:

public class SampleTestCase extends JuxyTestCase {
  public void testListTransformation() {
      newContext("stylesheet.xsl");
      context().setDocument("" +
          "<list>" +
          "	<item>item 1</item>" +
          "	<item>item 2</item>" +
          "	<item>item 3</item>" +
          "</list>");
      Node result = applyTemplates();
      xpathAssert("text()", "item 1, item 2, item 3").eval(result);
  }
}

and here’s a near-equivalent XML test case:

<test name="MoreThanOneElementInTheList_ApplyTemplates">
  <document select="/list"><list><item>first item</item><item>second item</item>
<item>third item</item></list></document>
  <apply-templates select="/list"/>
  <assert-equals>
    <expected>first item, second item, third item</expected>
  </assert-equals>
</test>

Testing for the correct result is the easy part. All the XSLT-only testing frameworks do the job when you’re just testing the happy scenario (my new phrase for the week, picked up from here). One reason for going outside XSLT is testing for <xsl:message terminate="yes">, which would make an XSLT-only test framework crash and burn along with the stylesheet under test.

The following Juxy test causes the stylesheet processing to terminate, but Juxy just records that the assert-error assertion was true, rather than Juxy terminating as well:

<test name="Stylesheet">
  <stylesheet href="xmlTest/x2j.xsl"/>
  <document><stylesheet href="href"><root/></stylesheet></document>
  <assert-error>
    <apply-templates/>
  </assert-error>
</test>

Does anybody know of an open source toolkit that can produce that sort of graphical representation?

Most XSLT unit testing frameworks are written purely in XSLT; that is, the framework uses an XSLT processor and XSLT stylesheet to run the tests (or a massaged form of the tests) on the stylesheet under test. The test result output is typically XML that is processed by another stylesheet to produce HTML for viewing.

Using XSLT to test XSLT may be partly explained by XSLT being an XSLT practitioner’s favourite tool and partly by Eric van der Vlist’s XSLT-based XSLTunit being the first known framework. Jeni Tennison’s possibly unnamed framework is also purely XSLT (though XSLT 2.0 instead of the XSLT 1.0 in XSLTunit), and it inspired the Tennison Tests framework, which automates running the multiple tests but hasn’t tinkered with the XSLT nature of the tests, and also XTC.

By comparison, the frameworks that rely on compiling code to run tests are, it seems, much less well known. They include Juxy, which compiles Java code for JUnit tests, and XMLUnit, which has versions in Java for use with JUnit and C# for use with NUnit.

IMO, the extra-XSLT frameworks have the advantage that you can (or should be able to) make assertions about aspects of the stylesheet to which a pure XSLT framework is either blind or oblivious.

Inasmuch as you typically use xsl:message to output messages when there’s an error in the source document or there’s something that the stylesheet can’t handle, you should want to make assertions about whether or not a message has been emitted. This is particularly true when you are writing “dirty” tests that you expect will trigger error handling (as opposed to “clean” tests that you expect to work), and even more true when you expect to execute a xsl:message that has ‘terminate="yes"‘.

Pure XSLT frameworks don’t provide a way to tell when a message is emitted, and any <xsl:message terminate="yes"> will terminate the testing framework along with the stylesheet under test, leaving you with nothing. A good extra-XSLT framework will let you make assertions about xsl:message and will not evaporate when the stylesheet terminates itself.

When a stylesheet may create multiple result documents, you probably want to make assertions about the existence and content of those result documents. That could be left to a post-process, but if the file names and the content relate to the content of the source document, it is simpler and more self-contained when you could make your assertions in the same unit tests as you use to make assertions about the rest of the operation of the stylesheet. A pure XSLT framework can’t provide any indication that a result document was or was not created, though it may be possible to access a secondary result document as part of the unit tests (provided the XSLT processor finishes writing the secondary result document while the transformation-that-is-the-running-of-the-unit-tests is still in progress). An extra-XSLT framework typically lets you make assertions after the stylesheet-under-test has finished.

So while there are some aspects of XSLT processing, such as what happens on a xsl:message, that you as a stylesheet writer don’t need to concern yourself about, you as a stylesheet tester do want to know about them, so you need more that just an XSLT processor in the framework for your unit tests.