Re: [xsl] XSLT Unit Testing and Coverage

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

> is there a good reason to deploy a XSLT unit testing framework?

Yes it's essential!

> I have never
> seen any serious XSLT dev env where the XSLT unit testing was either done
> religiously, or considered mandatory.

If you are doing "serious" work then you need something to give you
confidence after making changes.

I have my own Java junit based test framework that allow me to do two things:

1) do xquery based asserts like this:

assertEquals(runQueryOnInput("/path/to/some/node"),
runQueryOnOutput("/path/in/the/result"))

the runQueryOnInput() and runQueryOutput() helper methods run xquerys
against the stored input and result docs.

2) Validate the result and/or do deep-equal() comparisons with some
expected doc.  The deep-equal approach is only occasionally useful
because unrelated changes can break a lot of tests.

XSLT often follows the structure of "specific imports common", and the
test framework follows that approach:

Specfic1Test extends CommonTest
Specific2Test extends CommonTest

Tests common to all go in CommonTest, and tests only for the SpecificN
go in there.  The good thing about this approach is it mirrors your
xslt structure, and allows the same overriding of tests as code in the
xslt.  Also, every time you add a new "specific" test class, you pick
up all the existing tests in common.

Ultimately this allows me to build up 1000s of focussed tests, on
hundreds of input files, each one comparing values in the input with
the result or checking for existence etc, and validating every result.
 It's all runs in seconds, and fits in with Java/Maven/Hudson for
continuous build.


-- 
Andrew Welch
http://andrewjwelch.com