[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT Unit Testing and Coverage

Subject: Re: XSLT Unit Testing and Coverage
From: "Vasudev Kandhadai vasu.kandhadai@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 30 May 2014 19:24:08 -0000
Re:  XSLT Unit Testing and Coverage
I have a very messy stylesheet written by some developer..
It has things like :

xsl:template name = "foo"

  for-each xx/yy[some predicate]/zz[some predicate]/abs
         value from an xpath from source
         value from another xpath from source
         value from another xpath from source

 value from another xpath from source
 value from another xpath from source
 value from another xpath from source

These I think is a bit messy to write a TEst case for?

I am not sure Xspec can be used for writing test cases for these scenarios?

I would have thought simple test cases like result of a function,
test cases for matching templates, where the source template is changed to
another name?
or something simple can be easily tested using the Xspec ... I can even
access the xspec RNG to figure out all the possibilities.

So are there definitely pointers to when the test cases can be written?

I see that it is probably a bit more easier to test the whole XSLT.. as
opposed to small fragments.. Like others have done, unless we start to
write our own XSLT unit testing framework, it is difficult to work with off
the shelf frameworks, especially those that are not maintained.

Btw, I am advocating of chunking the idea of coverage for xslt.

On Fri, May 30, 2014 at 8:23 AM, Michael Sokolov
msokolov@xxxxxxxxxxxxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>

> On 5/30/2014 8:00 AM, Andrew Welch andrew.j.welch@xxxxxxxxx wrote:
>> I wouldn't call these unit tests, though; they are more akin to
>>> so-called "integration" tests.
>> I wouldn't get too hung up about the distinction: if your entire
>> product is your xslt you might think of them as integration tests but
>> if your xslt is just a small part of some bigger application you might
>> consider them unit tests...
> Yes, the distinction wasn't clear. I just meant we don't tend to write
> tests for each template or function. Instead we test the transformation as
> a whole.
>>  Measuring test coverage we have also found useful, but less so.  My team
>>> invested some effort in getting Cakupan working but ran into some
>>> roadblocks
>>> and ended up implementing our own (Saxon-specific) solution.  We had a
>>> certain amount of discussion about whether line-oriented coverage metrics
>>> made sense for XSLT but ended up implementing that since it was easiest.
>>> One time coverage tools are very useful is when unlimbering old code that
>>> may not be well maintained: a coverage measurement can give an idea of
>>> how
>>> complete the test suite is, and may point areas of dead code.
>> I'm not convinced by test coverage yet - a lot of processing will
>> (typically) go through the identity template, and a single test
>> covering that will give misleading stats.  Any comments on that?
> I'm not really interested in stats (how many times a given code block was
> exercised) - is that what you meant? I just care whether there is at least
> one test covering each template.
> -Mike

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.