[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|