Database Reference
In-Depth Information
We import the XQSuite test framework XQuery module, so that we can subse‐
quently run our test suite.
We prepare a sequence of URIs of all modules that we are interested in testing.
You can add more modules to this sequence if you wish.
We call
inspect:module-functions
for each module we wish to test, to get a list
of all functions in all our modules.
We call
test:suite
, passing in all the functions. XQSuite will operate only on
those functions that have XQSuite annotations, so we need not worry specifically
about which functions we pass in.
Running the test runner should yield an xUnit result document that looks something
like:
<testsuites>
<testsuite package="http://example.com/record/id"
timestamp="2014-07-02T17:55:43.747+01:00"
failures="0"
tests="1"
time="PT0.023S">
<testcase name="insert" class="id:insert"/>
</testsuite>
</testsuites>
Note that the
package
name used in the xUnit output matches the namespace of
our module under test.
Here we can see how many of our tests failed. In this case there were
0
failures
,
so everything must have passed (succeeded).
Here we can see the total number of tests run. In this case there was
1
test
run.
The number of tests passed is calculated by
passed = tests - failures
; there‐
fore, there was
1
passed
test.
Here you can see the time taken to run a specific test suite. This can be useful for
measuring performance loss or gains when refactoring code.
Great! Now we have one test case that we can run that helps us prove the correctness
of our code and guard against regressions. What if we want more than one test case
per function? Let's now look at how we would add our second test case, which was:
Search WWH ::
Custom Search