Testing a Complex Decision with Many Tables - Gnorion/BizVR GitHub Wiki

Suppose you have a decision that has a lot of tables like this

How do you approach testing it?

Notice that the entire decision only has four inputs: A, B, C and D.

But what values and what combinations of these values do we need for testing.

If the entire decision is sent to the validator it will analyze all the tables and find all the values that these variables are tested against.

In this example it finds the following

A: = 'red'
B: = 'large', = 'small', > 100, <= 100
C: < 0, >= 0
D: in [0..100], < 0, > 100

Notice that for variable B it has found conflicting values. B cannot be both string and integer.

In fact the Validator will alert you to this in its conflict section as follows:

E002 ERROR: Conflicting data types found for conditions on attribute B.
Condition B is tested as integer in table T6 rule R1 but string in table T3 rule R1 
If one of the conditions tests an expression rather than a literal then check that the expression returns the correct data type
T6: R1: IF B > 100 THEN T6='T6A'
T3: R1: IF A = 'red' and B = 'large' THEN T3='T3A'

So before we can even execute this model these errors need to be fixed.

Lets assume we have fixed them and now the values are

A: = 'red'
B: < 100, > 100, <= 100
C: < 0, >= 0
D: in [0..100], < 0, > 100

Note that B is tested in two different tables (T6 and T3) with slightly different conditions. But as long as the data types are consistent this is ok.

Now the question is: "What combinations of these values is it reasonable to test?"

Validator will do the math and determine that there are 18 combinations that should be tested. It will also generate them all as json as follows, basically choosing values at or around the boundaries of the conditions.

But what if there were a lot more values being tested in the rules? You could end up with thousands of possible test cases.

Is that really necessary?

A better approach is to start by testing tables individually - there will usually be a lot less combinations to deal with.

The once you've "proved" each table separately you can test the entire collection

This is described here Benefits of Testing Tables Individually

This is described here Testing Related Groups of Tables