Automating the checking of results

We can add rules to the decision table to check whether the price determined by the rules is what the business expected by adding a field to the input json that contains the expected result. For example

Now when we run the test we can see which ones passed or failed:

What do we need to add to the decision table to accomplish this?

Here is the updated decision table:

Rule 4 is the one that does the important work of checking the price against the expected price

But notice that we have added some more actions:

• We set the default status of each test to FAIL. Only if the expected matches the actual price will this be set to PASS.
• We record the rule that was involved in making the decision
• We also describe the reasoning in a bit more detail

Of course someone has to determine what the expected price should be. Ideally that should be a business user who was not involved in creating the decision table. Essentially it serves as the acceptance criteria for determining if the decision solves the original business problem.

Discussion Point

Do we really need to have a test case for every possible combination of the input values? Is there a smaller set of test cases that would be just as good at proving the rules are correct?

Well, one approach would be to create a test case for each rule in the decision table. In this case that would be three test cases. But if all three test cases get a PASS does that mean the rules are correct. No, of course not. As we already saw the rules do not cover every possible combination of inputs. So the business needs to specify the prices for the missing cases.

Worse still the rules may be ambiguous (that is for the same input values there may be more than one possible price).

If you look closely at the table above you may notice a subtle change in rule 1. It now says "if color is red then price is 5". So what is the price of a large red square? Is it 5 (according to rule 1). Or, is it 15 according to rule 3 which says large squares are 15. Whether we get a price of 5 or 15 depends entirely on what order the rules get executed. So we really need the business to refine the rules to remove any ambiguity

More to follow on

• Checking the consistency of the rules
• Checking the completeness of the rules
• Checking the rules for redundancies
• Checking the rules for values set but not tested
• Checking the rules for values tested but not set
• Checking the rules for constraint violations
• Checking the rules for refactoring opportunities
• Checking the rules for circular logic
• Checking the rules for paths from the inputs to the outputs
• Defining an Ontology (Entities, Attributes, Associations)
• Including javascript libraries to extend functionality
• Defining different kinds of decision table
• Drawing graphs of the various dependencies within and across decision models
• • Dependencies between attributes
• • Dependencies between rules
• • Dependencies between decision tables
• • Dependencies between decisions