Database Reference
In-Depth Information
</testsuite>
</testsuites>
We can now see that all three of our test cases are executing.
Unfortunately, at present XQSuite shows the same
name
for all of our test cases.
We have now written our three test cases for our
id:insert
function, but what about
the
id:generate
and
id:random
functions? Well, of course, we could write some fur‐
ther test cases for these using XQSuite annotations—but wait a minute, maybe there
are some difficulties in testing these functions! These two functions have in fact been
written to illustrate problems that can arise in writing test cases.
First, let's consider the issues with the
id:random
function. This function, as its name
implies, will return something
random
each time it is called (in this instance, an
eight-character alphanumeric string). This function exhibits a trait known as
nonde‐
terministic
behavior
, which means that each time the function is called, it may pro‐
duce a different result. This makes testing harder, as in this case we cannot make
assertions about the exact return value of the function using the XQSuite annotation
%test:assertEquals
. Instead, we can only make generalizations such as “The result
must be a string of 8 characters” and “The result can only contain the characters
a
to
z
and
0
to
9
.” Unfortunately, this nondeterminism is spread throughout our identi‐
fier's module, as each function eventually calls
id:random
. We could solve this in
some test frameworks in other languages by introducing
mocks
that would effectively
replace the underlying call to
util:random
with some static value, which we could
then use as the basis for assertions about the deterministic results of our tests—that
is, asserting that our algorithm for encoding from numbers into a charset is entirely
correct. Regrettably, XQSuite does not yet support function mocks.
So, what about testing our
id:generate
function? Well, again, we have the nondeter‐
minism problems of
id:random
, but here they are amplified by the contents of a data‐
base collection because the database itself is in a
mutable state
, which can lead to even
worse nondeterministic results. Again, if only function mocking were supported, we
could provide a deterministic substitute for the database collection.
There are also other potential problems with how
id:generate
is
implemented and would be used in a multiuser system, but we will
leave that as a mental exercise for the reader.
However, all is not lost! If we were to change our
id:generate
function to take a path
to a collection as an argument rather than the currently hardcoded one, perhaps we
could create a
test collection
and prime it with deterministic data for our test case,
before we run it. Afterward, when we are done with the test data, we would be courte‐
Search WWH ::
Custom Search