OpenRules Decision Manager provides all necessary tools to build, test, and debug your business decision models. The same people (subject matter experts) who created decision models can create test cases for these models using simple Excel tables or objects coming from the outside world (from Java, XML, or JSON). This post explains how to create and use test cases and data tables.

Test Cases

Let’s start with a simple decision model “PatientTherapy” described here and included in the standard installation “openrules.samples“. The simplest way to provide data for testing this decision model is the following table of the type “DecisionTest” that describes 3 test cases:

Blue columns of the type “ActionDefine” provide test values for input decision variables. Reddish columns of the type “ActionExpect” provide expected values for the proper output decision variables. If the expected values do not match the actual values produced during the decision model execution (using test.bat) OpenRules will display mismatches. For instance, if in the Test 2 you replace the expected Recommended Medication to “Levofloxacin”, you will receive the following error:

This table is self-explanatory. The only column that requires an explanation is “Patient Allergies” that defines a text array of the type String[] with potentially many allergies. So, here we used two sub-rows to represent two allergies and cells in all other columns for the Test 1 were merged. Of course, you can add as many sub-rows as you need. Alternatively, you may list all allergies separated by commas inside a one cell as below:

DecisionData Tables

In more complex cases, it is more convenient to define separate data tables one for each business concepts. For instance, here is the data table for all test-patients:

In the left top corner this table specifies its type “DecisionData” following the business concept “Patient” (defined in the Glossary) and the names of the array “patients“.

Similarly, we may define an array “visits” that provides data for the business concept “DoctorVisit”:

We can use these two arrays “patients” and “visits” to define the same test cases as above but in a more compact way:

Here instead of 6 columns “ActionDefine” we use only 2 columns of the type “ActionUseObject“. Their cells refer to the elements of the arrays “patients” and “visits” using indexes starting with [0], e.g. patients[0] refers to the first element of the array patients, and visits[2] refers to the third element of the array visits.

References Between Data Tables

Sometimes you want elements inside one DecisionData table refer to arrays defined in other DecisionData tables. Here is an example from the project “OrderPromotion” from the standard installation “openrules.samples”.   The following DecisionData table defines an array “orderItems“:

And the next DecisionData table defines an array of order that specifies which order items from  the array “orderItems” belong to each order:

Here the second column has the second row contains the reference “>orderItems” that tells OpenRules that the names such as “AAA-1112” or “BBB-2639” are actually the references (“primary keys”) to the proper rows in the array “orderItems”. Please make sure that such “primary keys” are always defined as the first columns of the corresponding DecisionData tables and have type “String”.

Note. Instead of defining test data in Excel, you may read data from relational databases by using special tables of the type “DataSQL” – see http://RuleDB.com.

You may find more information in the User Manual for Business Analysts.