Re: [xsl] XSLT Unit Testing and Coverage

["Andrew Welch andrew.j.welch@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

> 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...

For example, in a larger application the xslt often need to call out
to Java, so to facilitate that you can use a use-when:

xsl:function name="aaa" use-when="function-available('mycomp:getAAA', 0)"

and then provide a mock for running outside of the application, or in
your unit tests:

xsl:function name="aaa" use-when="not(function-available('mycomp:getAAA', 0))"

Your unit tests can now run the transformation in isolation, asserting
that the code is behaving as it should based on the return values in
the mocks.  You can have an additional layer of tests using EasyMock
or similar...

Your integration level tests run the transform with the real
extensions available.


> 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?