[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: junit test... for xslt2?

Subject: Re: junit test... for xslt2?
From: Florent Georges <lists@xxxxxxxxxxxx>
Date: Mon, 8 Mar 2010 10:06:40 +0000 (GMT)
Re:  junit test... for xslt2?
Andrew Welch wrote:

  Hi,

>>  But for a few components, mostly template
rules, diffing
>> against an expected XML document is really what we need.

>
I disagree on this point

  I'd just like to insist on the fact I said "for a
few
components".  More precisely, I'd say very rarely for my own
components,
but people seem to need that (for better or worse).

> Ultimately though, for
checking the "correctness" of the result
> of a transform, I think you just
need to execute XPaths against
> it, which are more tolerant of subtle changes
in the output.

  A couple of remarks here.

  If we speak about the result of
a "whole transform", I tend to
see it as defined by an input and an output, so
the result can be
tested against an expected output.  As a few values can not
depend on the input (like generate-id()) we need a mechanism to
compare two
documents (where we can say: "do not compare text
nodes with whitespaces", or
"do not compare the value of the
attributes 'id'").

  But then this is more
"functional testing" than "unit testing".
For unit testing, I'd say one
component has only a few
responsibilities on the result it produces.  It does
not always
define its whole output.  Some parts are the responsibility of
other components (like called functions or other template rules).
And in unit
testing, I think assertion expressions (what I think
you mean by "you just
need to execute XPaths against it") is
really more convenient than comparing
two entire trees.

  Here is a simplified exerpt of a test suite for the
EXPath HTTP
Client:

    <t:call function="http:send-request">
       <!--
some param here... -->
    </t:call>
    <t:expect test="count($t:result) eq
2"/>
    <t:expect test="$t:result[1] instance of element(http:response)"/>
<t:expect test="$t:result[1]/xs:integer(@status) eq 200"/>
    <t:expect
test="$t:result[2]/*">
       <pass>...</pass>
    </t:expect>

  t:call is
the expression to test (calling http:send-request
with some paramaters omitted
here).  The first three t:expect
test assertions (the number of returned
items, the type of the
first one and the value of its attribute @status).  The
last
t:expect compare the child of the second item (which is a
document node)
to an expected value.  "..." means "everything" so
this is really like the
assertion "$t:result[2]/* instance of
element(pass)" but we can have a
slightly more complex example
where this is really more convenient to gather
several assertions
as one exerpt of the expected output than having a long
list of
assertion expressions like "the result must be one item, the item
must
be an element para, this element must have an attribute id,
this attribute id
must be an integer, this integer must be equal
to 1, the para must have ..."
Regards,

-- 
Florent Georges
http://www.fgeorges.org/

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.