Re: [xsl] junit test... for xslt2?

[Maurice Mengel <mauricemengel@xxxxxxxxx>]

Hi everyone,

I find the topic very interesting, but also pretty advanced and
difficult to follow. If there were a book on xslt testing I would
certainly buy it. So is there any interest in publishing such a book
or at least a book which includes a decent and recent chapter on xslt
testing? I assume there is none since I couldn't find one. It seems
that O'Reily's "Java and XSLT" is a bit outdated and a bit
superficial. I ordered it, but haven't actually looked at it.

Maurice

On Sat, Mar 13, 2010 at 12:52 PM, Maurice Mengel
<mauricemengel@xxxxxxxxx> wrote:
>
> Hi everyone,
>
> I find the topic very interesting, but also pretty advanced and difficult to
follow. I there were a book on xslt testing I would certainly buy it. So is
there any interest in publishing such a book or at least a book which includes
a decent and recent chapter on xslt testing? I assume there is none since I
couldn't find one. It seems that O'Reily's "Java and XSLT" is bit outdated and
a bit superficial.
>
> Maurice
>
>
> ----
>
> On Mon, Mar 8, 2010 at 11:48 AM, Dave Pawson <davep@xxxxxxxxxxxxx> wrote:
>>
>> On 08/03/10 10:43, Andrew Welch wrote:
>>
>>>> B Here is a simplified exerpt of a test suite for the EXPath HTTP
>>>> Client:
>>>>
>>>> B  B <t:call function="http:send-request">
>>>> B  B  B  <!-- some param here... -->
>>>> B  B </t:call>
>>>> B  B <t:expect test="count($t:result) eq 2"/>
>>>> B  B <t:expect test="$t:result[1] instance of element(http:response)"/>
>>>> B  B <t:expect test="$t:result[1]/xs:integer(@status) eq 200"/>
>>>> B  B <t:expect test="$t:result[2]/*">
>>>> B  B  B  <pass>...</pass>
>>>> B  B </t:expect>
>>>
>>> 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.
>>
>>
>> regards
>>
>> --
>> Dave Pawson
>> XSLT XSL-FO FAQ.
>> http://www.dpawson.co.uk