Re: [xsl] Unit tests in XSLT (was: Re: Controlling Debugging Messages)

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

On Mon, 15 Oct 2018 at 20:40, Pieter Masereeuw pieter@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> It would be interesting to know if there are readers on this list who
> actually make use of units test during XSLT development and what their
> experiences are.
>


The last time this subject came up I remember there was some debate about
what constituted a unit test versus an integration test.

Personally I've always used a custom junit test framework which is along
the lines of "property based tests".  The transform is run once per test
class and the test methods are like:

@Test
public void testFooIsMappedToBar() {
    assertEquals(runQueryOnInput("/path/to/foo"),
runQueryOnOutput("/path/to/bar"))
}

This is running an xpath (or xquery) on the input xml, and another one on
the output xml, and checking they are equal.  It's not checking any logic
in the xslt, just that the output value is as expected.  If you are into
TDD you can write these tests first, and then implement the xslt.

The important part is that the test classes are arranged in the same way as
the xslt, eg if the xslt is arranged as 2 primaries importing a common:

primary1     primary2
      \                /
        common

...then the test classes are arranged as:

      base class
 /                    \
subclass1     subclass2

This allows tests to be added to the base class that apply to all
transforms, and tests that are specific to a particular primary xslt to be
in the common.

The same applies for the testing same pimary xslt with different inputs (or
scenarios), eg:

              base class
           /                            \
       subclass1                   subclass2
   /          /       /        \                \         \
sc1a    sc1b   sc1c  sc1d       sc2a   sc2b

Here there are 4 leaf classes for subclass1 all testing different inputs,
and 2 for subclass2.    These leaf classes contain the setup for the
transform, such as the input and the parameters.  The xslt and xsd for the
result can be defined at the appropriate point, such as "subclass1" and
"subclass2".

There are two main benefits to this:

1) When you add a new leaf test class, it automatically picks up all the
tests in its parent class.  Say for example you have 1 input xml that is
causing a problem, you can add a new leaf class with that input and all
your existing tests will be run against it.

2) You can add a test method at the relevant point in the hierarchy and
have all the appropriate test scenarios run that test.  For example, if you
change something in your common xslt you can add a test method to the root
base class and be confident every test scenario will run that test.  If you
change something in your primary xslt, you add the test to relevant test
class in the hierarchy.  If it's just for 1 input (or scenario) then the
test goes in the leaf class.  This is a really powerful way of ensuring a
change in some part of your xslt is tested fully by all your existing tests.

To do this, to be able to write a test in a part of the hierarchy that will
work with any potential input supplied via a subclass means you have to
write your tests in the "property based tests" style... but once it's like
that you can supply 1000s input of files and be confident your xslt is
correct.


-- 
Andrew Welch
http://andrewjwelch.com