ATDG01

back to Importing Excel Spreadsheets into BizVR add comments here

Automated Test Data Generation

Suppose you want to test this decision table

Let's suppose we want to test with color: red or green, size: large or small and shape: square or round

Some simple math tells us there are 2 (colors) x 2 (sizes) x 2 (shape) = 8 possible combinations.

You could hand write all the possible combinations of the values of color, size and shape. In this example there aren't too many. But if there were more values this could get tedious. Fortunately its possible to write a decision table to generate all of thee automatically

First you need to decide what values are important and describe them in some JSON eg:

{"COLORS":["red","green"],"SIZES":["small","large"],"SHAPES":["square","round"]}

Then you can create a decision table like this:

This will output all possible combinations of the input values. You can then copy and paste that JSON into the input of your pricing decision. Obviously you cannot use this technique to generate expected results - someone on the business side has to know what answer they are expecting.

Although if the person developing the tests wrote their own version of the pricing rules you could use that to provide the "expected" results. Then running the tests would flag any variation between the results produced by the two decision tables. This would, at least, provide two independent checks on the correctness of the rules.

Of course, as we all know, often it is the specification for the rules that is the source of the errors and having two people develop rules from the same spec is not going to resolve that.

You might argue that we should include test values for other than red, green and other than large, small and other than square, round, And indeed we could do that by adding "other" to the list of values. But now if you autogenerate test data there will 3 x 3 x 3 = 27 test cases. 19 of which will include at least one "other" value. Since the decision table currently has no rules to deal with "other" you won't get a price.

So instead of testing 19 combinations of "other" you could simply run three test cases each with "other" for color,size and shape. You won't get a price set in these cases so if you want to detect when an unexpected value is sent to the rules you might consider adding a decision table solely to generate an error message when an invalid values is received. If there are other valid values that the rules should handle then they need to be added.