[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLT Unit Testing and Coverage

Subject: Re: [xsl] XSLT Unit Testing and Coverage
From: "Lizzi, Vincent vincent.lizzi@xxxxxxxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 29 May 2014 00:55:01 -0000

XSpec is what I use. It's integrated in oXygen XML Editor which makes it very
convenient, or you can get the source and run from command line. XSpec gives
you a lot of freedom in how you write your tests; you can write scenarios for
individual templates and functions, or inspect the output of an entire
transformation. I find it helpful to write test scenarios first and then write
the XSLT, and it's also helpful in the opposite way to write test scenarios
for existing XSLT.

Another method is to have a set of control documents with source files and
output files from the XSLT. Any change to the XSLT can be tested by running
source documents through the XSLT, and then compare the output files against
the control documents using diff, WinMerge or any similar program. This is
simple and effective, but has limitations. For example, if you have
differences in output that can safely be ignored (such as generated
timestamps) a diff report would show the difference but in XSpec you can just
write ... to ignore the difference.


From: Michael Kay mike@xxxxxxxxxxxx
Sent: Wednesday, May 28, 2014 6:06 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] XSLT Unit Testing and Coverage

First, I think we need to be clear what we mean by "unit testing". I've seen
some projects where people have large numbers of tests for purely internal
functions and methods. I've never seen much point in that, and it can greatly
increase the cost of doing internal refactoring. On the other hand, having
lots of tests for external functionality can be very useful indeed. For XSLT,
that means tests of complete stylesheets, rather than tests of individual
functions and templates.

If you are changing your system to use a new technology, e.g. changing XSLT
processor or changing from XSLT 1.0 to 2.0, then having a good set of test
material for your stylesheets turns it from a very high-risk undertaking to a
very low-risk one. It also greatly reduces the risk of making enhancements to
your stylesheets, e.g to incorporate enhancements to the source document
schema. So it is something I would recommend every project to have.

Whether you do this with an off-the-shelf framework like XSpec or with a
home-grown test approach matters less.

Michael Kay

On 28 May 2014, at 19:57, Vasudev Kandhadai
rytech.com>> wrote:

Dear All,
is there a good reason to deploy a XSLT unit testing framework? I have never
seen any serious XSLT dev env where the XSLT unit testing was either done
religiously, or considered mandatory.  Other than a very religious Java
development team with strict Junit set up with Maven etc, who have adopted
XSLT into their dev env, who would now want to extend the same ideologies to
the XSLT world?  I have personally never used or utilized practically any XSLT
unit testing framework in any project and nor was there any requirement to do

So considering we need to do this, I came across,
XSPEC, XUnit etc.. Xspec seems like a good one,  but doesnt look like a lot of
discussions are  happening in the community.. The Coverage feature doesnt work
The class is not being maintained.

Cakupan, was very hard on my brains to read the manual.. Again something that
has been out there for a while and not sure it is still maintained /

Does anyone has any ideas on what options we have in the XML world for
XSL Unit Testing + Coverage Report

I tried posting to the Xspec community but no one bothered to answer my
questions , so I am inclined to think it is dead.

Somehow I am also inclined to think Coverage feature is a very Java/C#/C/C++
paradigm... Doesnt make too much sense with the XSLT world?

Your inputs are valuable.
XSL-List info and archive<http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe<-list/293509> (by email)

XSL-List info and archive<http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe<-list/194671> (by email<>)

Current Thread