Expect to spend the same amount of time testing as building the decision model in the first place.

Step by step

Work from the top of the Decision Model down. For each group of simple decisions, or for individual complex decisions, create a basic test document with the same name as the group or decision. This document only needs the actual fields used by the group or decision for this level of testing.

Turn off all other groups and decision using the action=’none’ option.

Run the document inside the inline debugger. If an incorrect result is provided, then inspect the formula and correct. If the fault is not obvious, then set a breakpoint on the decision and repeat. ‘Stepping in’ to the decision and inspecting the individual operation results usually identifies the cause of faults.

Be aware that a decision that appears to be operating correctly under debug and which then does not deliver the correct results may be being overwritten or rolled back by a subsequent decision - check for this.

Comment the group or decision when tested and move down to the next group or decision.

This approach provides fine grained testing, and is likely to locate most bugs in your logic.

Use case testing

When completed, prepare or acquire some test documents that represent actual use cases and review these using the inline debugger.

When the process is deemed correct, keep each valid and approved output document in a folder along with its input document (the naming convention inputdocumentname.out.xml is useful for this). These output documents can be used as reference documents for regression testing using the Text Executive (not available to IDIOM Lite users).