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
<result>
value from an xpath from source
</result>
<result1>
value from another xpath from source
</result1>
<result3>
value from another xpath from source
</result3>
/for-each
<outer>
value from another xpath from source
</outer>
<outer1>
value from another xpath from source
</outer1>
<outer2>
value from another xpath from source
</outer2>
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(_at_)safaribooksonline(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
wrote:
On 5/30/2014 8:00 AM, Andrew Welch
andrew(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com 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
--~----------------------------------------------------------------
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
--~--