(: a test definition :)
let $test :=
<test>
<method>
let $book:= /bib/book
</method>
<asserts>
<assertTrue name="count nodes">
return count($book) = 4
</assertTrue>
<assertTrue name="find by name">
return $book[1]/title = "TCP/IP Illustrated"
</assertTrue>
<assertTrue name="find by author">
return count($book[author/last = "Stevens"]) = 2
</assertTrue>
<assertTrue name="find by author case sensitivty">
return count($book[author/last = "stevens"]) = 0
</assertTrue>
</asserts>
</test>
looks better from a naming point of view, it gives a better idea of intent and opens up the options for other kinds of asserts.
Once we apply a schema to this model, the xqunit:excute function can be locked down to expecting an assert rather than any node...
2 comments:
Are you sure it's a good idea to quote the actual test code? This would be like writing Java Unit Tests by having a huge String with the Java code, and then somehow eval'ing it.
You certainly loose a lot of tool support this way, and it somehow just seems wrong. Plus, relying on xdmp:eval is of course non-standard functionality.
Martin - thanks for the comment.
in response, the method tag could just be a call to an existing function - the amount of code in this element would be up to the tester. I view the method as being similar to a test function in java, you put into the code to test a function. But point taken.
In terms of xdmp:eval, I was using this as I'm in MarkLogic land - I would hope in the longer term to remove this limitation. Hopefully tests will work on any platform without change, it would be the frameworks responsibility to work out how to run the tests...
thanks for the feedback I will take them onboard - especially about xdmp:eval
Post a Comment