How to write a Test

Follow these steps to create a test for your processes, before you take them live:
Create a Test
You can find the Tests screen under 'Support' in the configuration menu.
Click on 'Create Test', and the following screen pops up:
​
Field
Description
Name
Give the test an easily identifiable name, for example the process it works on.
Process
The drop-down menu shows all available processes on the system. Choose the one you create this test for.
Click 'confirm'. The new test is now added to the overview screen, with 'Not Run' as its status.
​
Configure a Test
A test run of a process is successful, when the outcome matches your expectation.
To configure a test, select it from the list. This gets you to the following screen:
Field
Description
Name
The name of the test.
Process
The process this test will run on.
Situation
Using YAML, describe your starting assumption.
Assertion
Using YAML, describe the outcome you expect from the process.
Output
The actual output of the process, once the test has run.
​
A Quick Word on YAML
YAML is the language used to describe the starting assumption and outcome assertion for tests.
Different from many other formatting languages, YAML is extremely straight forward. It does not require using brackets - curly, square, or otherwise - , stays clear of closing tags, and many other features that make a computer language seem daunting to the uninitiated.
YAML is a clean way to write data in a natural, concise, and easy to read manner. The structure of what you write, is determined by indentations. This makes it very intuitive.
How you configure a test using YAML, is best shown through an example.
​
Example
You have just finished configuring a process, that will update a risk profile. Before putting it live, you want to test whether the process gives you the outcome you want from it.
First, create the test as explained above. It will show up in the Tests overview with a ‘Not Run’ status.
Next, click on the test to get to the configuration screen. What should be written in the fields you see there, is explained below:
​
Situation
Let's say we have added a new document, named info_sheet_risk_&_product, to the client onboarding process. The document collects information on a client's investment expertise, goals, and risk willingness. We only want it to show up in a process, if the client has shown interest in investment products, and wants only passive advise from the bank.
To accomplish this, the document's configuration has as condition:
1
cr is ContractualRelationship
2
cr.services_of_interest_offering contains investment and then
3
cr.investment_product = passive_advisory
Copied!
To test whether we have set up everything correctly, meaning the document shows up only under the right circumstances in a client onboarding, we test run the process.
In the configuration of the test, in the Situation field, describe the data of a case you would like to test.
In our example, where we want to test whether the info_sheet_risk_&_product shows up when needed, this means under Situation, we describe that we are dealing with a client who is interested in investment services and wants passive advisory.
This Situation written in YAML is:
1
ContractualRelationship:
2
   services_of_interest_offering: investment
3
   investment_product: passive_advisory
Copied!
The first line describes the instance of the ontology 'ContractualRelationship' in our test case.
Lines 2 and 3 contain two information keys, plus their respective value.
Before you write the information key, begin the line with three spaces. This creates the characteristic YAML-indentation, which tells the system the information key belongs to and falls under the instance.
If you want to add another instance and its information keys/values, add them below the first one, using the same writing style.
In describing a Situation, if the value for an information key comes from a taxonomy, you wrap it in square brackets and single quotation marks. For example,
reference_currency: ['chf', 'usd']
​
Assertion
Next, describe your assertion of what the outcome of the process's test run should be. This can contain any or all of these four parts:
Instances: on the following line, write the key of the ontology, for example 'Person'. Use indentation. On the next line, specify one or more values using the Information keys as discussed under 'Situation' above. Again, use indentation to mark that the values are child parts of the parent ontology. Adding values to the ontology is optional.
​Documents: list the id numbers of the documents you expect to be added to the process.
​Sections: list the id numbers of the sections you designed to be added to the process.
Issues: list the id numbers of the rules you expect to be attached to the process.
All id numbers can be found in the configuration. Click on, for example, 'Documents' in the configuration menu. Take the id (only the numbers, not the prefix DOC-) from the first column of the Documents overview screen.
Continuing our example, the document info_sheet_risk_&_product has ID number 1633 in our configuration, as shown below:
In our test configuration, write the Assertion this document will show up in the process under the given Situation in YAML as follows:
1
Documents:
2
   - 1633
Copied!
Add as many Documents, Instances, Issues, and Sections you wish to test to the Assertion, listed by their ID numbers.
A test will be marked 'Passed' if all elements of the Assertion are present in the Output. If not, the test status will be marked 'Failed. If there is a language error in describing the Situation or the Assertion, for example by forgetting a colon : after Documents, the test status will show as 'Exception'.
​
Output
The test run from our example has as Output:
1
Universe contains a total of 2 objects:
2
  1 instances
3
  1 documents
4
  0 issues
5
​
6
<Instance: ultramarine-seagull> of 623
7
  services_of_interest_offering: investment
8
  investment_product: passive_advisory
9
  type_of_account_2: None
10
  risk_willingness_sum: 10
11
  risk_willingness: 5
12
  investment_horizon: None
13
  risk_willingness_enum: five
14
  liquidity_level_exp: None
15
  risk_capability_sum: 12
16
  risk_capability: None
17
  risk_capability_enum: five
18
  risk_class: None
19
  recommended_product: high_risk_product
20
  satisified_with_recommendation: None
21
  selected_product: None
22
  real_estate_level_exp: None
23
  investment_goal: None
24
  interest_bearing_securities_level_exp: None
25
  stocks_equity_funds_level_exp: None
26
  alternative_investments_level_exp: None
27
  foreign_currency_level_exp: None
28
  
29
Document of rule 1633
30
  <MatchedInstances: {'cr': <Instance: ultramarine-seagull>}>
Copied!
This means:
Lines
Explanation
1 thru 4
The 'universe' the process test run created: 1 instance, and 1 document.
6 thru 27
Information on the created instance, which all comes from the information on the one added document.
7 and 8
In our 'Situation' we only provided values for these two information keys. These two lines show that information to be present in the case.
29 and 30
Confirmation that document 1633, the info_sheet_risk_&_producthas been added to the instance. As that is the only thing we described in the Assertion, all of the Assertion evaluated as true and the test is marked 'passed'.
In the application, this looks as follows: