Tests
For configurations of Number range, Event handling and Association criteria, a test mode can be entered via the editor.
Tests runs consider the status visible in the editor even if the configuration has not yet been saved or the edited element is defined as 'inactive' (where applicable). Thus, the effect of new or altered configurations can be verified or experimented with under laboratory conditions. It is also possible to 'test drive' existing configurations against a series of 'scenarios' using combinations of virtual data objects and variable values, without having to prepare such data in the systems database. Such scenarios can be saved as so called 'test sets' in the context of the tested object, to enable reruns of the test at minimum effort.
►NOTE◄ Although test sets appear closely linked to the object they were designed for from a user interface point of view, they are not included in the data object itself. Therefore, copying a data object does not create duplicates of test sets. For the same reason, permissions and ownership (see following section) as well as common events (see Common action event) are handled independently for test sets and tested objects.
Access control
Test runs with a specific data object ('test object') can be executed by any user with access to the details view for the test object. This requires a permission to 'Show details' or a combination of 'Read' with at least one of 'Create', 'Update" or 'Delete' in the definition of the role used. Tests with data objects owned by another company require a company authorization ('Read') for the object type.
Access to test sets is controlled by dedicated permissions on role-level and, possibly, company authorizations. Whether a user is categorically permitted to create, update or delete test sets is defined by the role. Since the owner of a test set may differ from the owner of the test object, it is possible to create an own test set for a foreign object. In this case, even the owner of the foreign object depends on company authorization to receive access to the test set. Vice versa, company authorization may be required for reading, executing, updating or deleting foreign test sets. An own version of a foreign test set can be copied based on company authorization to 'read' (the original) and a role permission to 'create' a test set.
Starting test mode
To enter test mode select Begin test in the ribbon of the editor for any of these objects.
Different ribbon options and object specific details appear in test mode (example: Event handler):
Test mode is started with a new test set, so test runs are possible immediately. The new empty test set can be used for ad hoc testing without ever being saved.
It is possible to Save (3) and Load test (4) individual tests. It is possible to Open last test (5), even if that test was not explicitly saved. Run test executes the current test.
►NOTE◄ A new test object, e.g. a newly added association criterion, can be tested before being 'created' (by saving for the first time). However, test sets for a test object can only be saved once the test object has been created, because the unique object ID is required as a reference.
Test for configurations of association criteria and event handlers may be restricted to a specific element, by starting test mode from the context menu instead of the ribbon. This is applicable for three types of elements:
Tests for rules (see image below) return the Boolean result of the rule.
Tests for actions execute the action and may return the input value (object) as a result.
Tests for values return the result value of contained resolvers.
Define a test set
A Testing set is identified by a Name (1) and combines an Input value and Variables.
►NOTE◄ Test-sets are independent objects, so common events (see Common action event) are applicable. For example, an event handler responding to events 'New' and 'Copy' could preset the Name of a new test-set with the user of the current session and a timestamp. Otherwise, test sets saved without the optional indication of a name are only represented in the list of choices for Load test by their rather uninformative ID. And it would prevent the risk of redundant names for copies.
For Event handler testing (see image) an Action event can be specified as the trigger for the test.
For Number range testing (not in the image) the parameter Preview count defines how many numbers to generate as a preview during the test.
The tab Input value defines input data for the test.
For Event handler testing, the input value is the XML representation of a data object that can be referred to in the event handler.
For Association criteria testing, the input value is the XML representation of a data object to evaluate in rules.
The Variables tab may contain XML code to define variables and their values to consider in the test.
The following code sample shows a variable named 'variable_name' with text value 'variable_value':
<?
xml
version
=
"1.0"
encoding
=
"UTF-8"
?>
<
core
:Storage
xmlns:xsd
=
"http://www.w3.org/2001/XMLSchema"
xmlns:lic
=
"SCM.LIC"
xmlns:core
=
"CORESYSTEM"
>
<
data
>
<
entry
>
<
key
xsi:type
=
"xsd:string"
>variable_name</
key
>
<
value
xsi:type
=
"xsd:string"
>variable_value</
value
>
</
entry
>
</
data
>
</
core
:Storage>
Each test set may contain a specific combination of 'input value' and 'variables' to define a certain test scenario.
►NOTE◄ The XML structure of a shipment can be assigned as input value for an event handler test set by the following simple procedure:
Select shipment of choice from in an overview ► click 'Show XML' from the Export-Ribbon ► copy (all) XML code ► paste into 'input value'
The XML code in 'input value' can be edited manually to create variations of test set scenarios. To achieve significant test results, be careful to create 'input values' that resemble the format of real data objects.
►NOTE◄ A test set created in a test session that refers to a specific element of an association criterion or event handler does not contain a reference to that element, but only the test object. Conversely, all test sets available for a test object can be used for testing any element of the test object.
Running a test
In the context of a test run a Boolean variable 'isTest' is set, which can be referred to by rules within the test to apply specific logic or behaviour in a test situation.
When a _data profile is called the following two variables as set/reset: VAR_IS_TEST (true during testing, otherwise false) and VAR_IS_NOT_TEST (false during testing, otherwise true).
Test results
Running a test populates the tabs in the lower half of the test mode view.
The Result tab shows results depending on tested object.
When testing Association criteria, the only result is a Boolean value of true or false.
When testing Number ranges, the result is a list of numbers generated as a preview.
When testing Event handlers, the result shows the final state of the data object in XML representation.
The Log tab reads a structured log file documenting steps of the test run. Individual sections of this file can be collapsed for better readability (1).
The Variables tab lists the data stored in variables by the end of the test run.