A unit test space contains unit tests that are run by the XUnit test manager. Because the XUnit manager is external to the unit test space, all test resources described in this document must be publicly available.
A unit test space publishes its tests by exposing the resource res:/etc/system/Tests.xml. This resource provides a list of testlist resource identifiers. The structure of the Tests.xml must be:
Where each test element identifies testlist using the following structure:
By convention the address space used for unit tests starts with res:/test/. This fileset definition will publish the test address sub-space:
A testlist contains a list of unit test definitions. When the group of tests defined by a testlist are executed by the XUnit test manager, they are executed in document order.
If the unit tests in a testlist require external resources such as assert libraries, these may be imported with the import element which identifies the library:
It is also possible to use import to include further groups of tests into a testlist:
Each test in a testlist specifies an individual unit test. A unit test is simply a set of declarative requests where the outer element specifies the role it plays in the unit test ( setup, test request, assert, teardown):
The XUnit test manager uses the name of each declarative request to determine when to issue the request according to this sequence of steps (possibly modified if exceptions are thrown):
The test request element is the only required part of a unit test. It defines a resource request issued into the unit test space by the XUnit test manager.
The following request definition
will cause XUnit to issue a SOURCE request for active:toUpper with an argument named operand which identifies a resource to convert to capital letters and with a required representation class of java.lang.String.
A test setup declarative request is optional and specifies a resource request that is executed prior to the test request.
The following setup declarative request will execute a Groovy language script prior to the execution of the unit test request:
A test teardown declarative request is optional and specifies a resource request that is executed after the test request.
The following teardown declarative request will execute a Groovy language script after the execution of the unit test request:
An assertion is a boolean test run against the resource representation
returned from a test request.
For example, you may assert that the representation is an instance of the
or an instance of the class java.lang.Boolean
with the value
A unit test is considered a success (it "passes")
if the request runs and all assertion tests evaluate to
The unit test framework will report the success or failure of each test,
each group of tests and all published tests as a whole.
The assert element may contain zero or more specific assertions that are run, in document order, against the result returned from the test request.
For example the following assert specification will cause the XUnit test manager to first check to make sure the time taken to process the test request was less than 20 milliseconds and then checks to make sure the returned representation is a Boolean with the value true:
If any assertion fails then the unit test fails and XUnit test management tool reports the failure in its report. Available assertions include built-in assertions, custom assertions (included in the testlist) as well as imported assert libraries.
It is often useful to be able indicate that a collection of tests are intended to test a specific module (or modules).
This can be done by simply declaring the module associations in the
The value of declaring a module association is that when you view a module in the space explorer, the context menu for a module offers "Execute Tests..." which will take you to XUnit with the associated tests for that module filtered out and ready to execute.
Here is a test list that performs two tests: a simple source test on a resource and an invocation of a script engine.