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/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--