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