[XSL-LIST Mailing List Archive Home]
Re: [xsl] junit test... for xslt2?
Subject: Re: [xsl] junit test... for xslt2?|
From: Dave Pawson <davep@xxxxxxxxxxxxx>
Date: Mon, 08 Mar 2010 10:48:07 +0000
On 08/03/10 10:43, Andrew Welch wrote:
Here is a simplified exerpt of a test suite for the EXPath HTTP
<!-- some param here... -->
<t:expect test="count($t:result) eq 2"/>
<t:expect test="$t:result instance of element(http:response)"/>
<t:expect test="$t:result/xs:integer(@status) eq 200"/>
Ok this is a good example of the concept behind xchecker... that test
can easily be rewritten in XSLT - what you gain from the framework you
also lose in it restrictions (failure messages, variables etc).
There's nothing wrong with that at all by the way, I just think a
slightly different (and better) approach is possible.
Is this a case of needing something 'outside' of XSLT?
Perhaps a simple Java framework to allow for testing failures?
Call the transform with 'bad' data to trap all the xsl:message
terminate='yes', then having done that, move in to XSLT
to test for 'good' paths?
Any failures in this second phase are definitely terminal.
XSLT XSL-FO FAQ.