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.
Cheers,
Vincent
From: Michael Kay mike(_at_)saxonica(_dot_)com
[mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com]
Sent: Wednesday, May 28, 2014 6:06 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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
Saxonica
On 28 May 2014, at 19:57, Vasudev Kandhadai
vasu(_dot_)kandhadai(_at_)gmail(_dot_)com<mailto:vasu(_dot_)kandhadai(_at_)gmail(_dot_)com>
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)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...
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 / supported.
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.
Kandha.
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<>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--