Understanding Test Results - xspec/xspec GitHub Wiki
Result and Expected Result use three colors to highlight the differences.
Details
| Color | Meaning | Significance |
|---|---|---|
 |
Same | These portions of nodes match each other. |
 |
Inner difference | These nodes have the same name, but they are different somewhere inside. |
 |
Different | These portions are where the nodes are different. |
x:expect/@test has dual functions depending on whether it's xs:boolean or not. Reflecting its duality, the right-hand side of the test result is either Expected Result or Expecting.
Details
($x:result is the actual result of the tested function or template.)
@test |
Left-hand side Result
|
Right-hand side title | Right-hand side contents |
|---|---|---|---|
xs:boolean |
$x:result |
Expecting | XPath expression in @test. You expected this expression to be true when evaluated in the context of $x:result
|
Not xs:boolean
|
Result of @test evaluated in the context of $x:result
|
Expected Result | Your expected item(s). You expected @test to be this item(s) when evaluated in the context of $x:result. |
| Does not exist | $x:result |
Expected Result | Your expected item(s). You expected $x:result to be this item(s). |
For the details about @test duality, see Expectations.
Wondering why a test fails when the contents of Result and Expected Result look exactly the same? Check out XPath above the contents.
Example
In this example, XSpec expects a document node while the tested stylesheet generates an element node.
- The expected document node contains an element node which is exactly the same as the element node generated by the tested stylesheet.
- That's why the contents are all green.
- Having said that, the test fails.
- That's because a document node and an element node are two different node types.
You can find the node types in XPath ... from above the contents. Note that reflecting their mismatch, they are colored in 
The best way to fix the above example depends on what you actually expect the tested stylesheet to generate.
-
If you expect the tested stylesheet to generate a document node, fix the stylesheet to do so:
<xsl:template as="document-node(element(foo))" name="my-template"> <xsl:document> <foo><bar>baz</bar></foo> </xsl:document> </xsl:template>
Note also that it's always a good practice to declare your desired node type clearly by setting
@asinxsl:template. -
If you expect the tested stylesheet to generate an element node, fix XSpec to expect so:
<x:expect href="xpath-from.xml" label="Expect an element" select="foo" />
Also, it is strongly recommended that you declare your desired node type clearly by setting
@asinxsl:template:<xsl:template as="element(foo)" name="my-template"> <foo><bar>baz</bar></foo> </xsl:template>
Grey \t, \n, \r and ␣ characters represent whitespace characters in whitespace-only text nodes.
Details
| Character in whitespace-only text node | Reported as |
|---|---|
U+0009 |
\t |
U+000A |
\n |
U+000D |
\r |
U+0020 |
␣ |
Note that this notation is applied only to whitespace-only text nodes. It is not applied to usual text nodes containing non-whitespace characters.
XSpec handles whitespace-only text nodes in special ways. See Whitespace-only Text Nodes for details.
<pseudo-*> elements in the reported contents such as <pseudo-attribute>, <pseudo-map>, etc. represent complex results that cannot be expressed directly.
Details
<pseudo-*> |
Item |
|---|---|
<pseudo-array> |
array(*) |
<pseudo-atomic-value> |
xs:anyAtomicType |
<pseudo-attribute> |
attribute() |
<pseudo-element> |
element() |
<pseudo-function> |
function(*) |
<pseudo-map> |
map(*) |
<pseudo-namespace-node> |
namespace-node() |
<pseudo-other> |
This item cannot be expressed by the current XSpec reporting system |
When reporting results of large documents, they get output as separate XML files (result-*.xml) rather than embedded directly in the report HTML.
You can inspect the results by clicking their links in the report HTML.
If you are running XSpec on Oxygen, the separate XML files may be deleted after running your tests. In that case, duplicate the built-in Run XSpec Test transformation scenario and set clean.output.dir = false in the Parameters tab. Run it instead of the built-in Run XSpec Test transformation scenario. The link in HTML may be still broken, but the XML files should be found in xspec folder relative to the XSpec file.
