(This is an article about testing in DROOLS, but with some general points of interest. Another write-up on a simple extension to use-case documentation that automates rules testing is in the pipeline.)
DROOLS is one of the most difficult BRMS systems to test, despite the close integration with products like JUNIT. Part of the problems lie with the lack of visibility of processing on the LHS, and partly with the interaction of some of the features.
A typical error arises when salience is used in conjunction with no-loop, in a DRL with multiple rules, some with the same salience: a common structure. Developers may think that no-loop means the rules won’t fire twice, and that salience guarantee to sequence the rules will fire: neither is true. Further, using salience at the same level can result in very elusive bugs that will escape simple testing.
Using ruleflow and pattern-rules goes a long way to reducing these problems. The ruleflow separates rules completely, so that technical interactions between rules are eliminated.
[Note that business interactions between rules are not eliminated. This is an important subject, requiring organizational and technical safeguards (esp. idempotence).]
For exceptionally complex rules, we also recommend testing the LHS separately from the RHS: the tuples to be created by the LHS should be specified, and tested.
For Rete based rules engines, I also recommend that, for all rules using facts with a one-to-many relationship, that the test be repeated with the facts shuffled, i.e. inserted in a different order. This was as a result of validating the user testing on a large project and finding the 30% of the rules contained subtle and different errors, that only arise when the test data is shuffled, and not in the sequence the developer expected. This testing can be completely automated.
Equally, null entity testing can be partially automated: each of the tests can be carried out with one of the fact entities completely missing. This does require effort to interpret the results.
I also recommend as graphical a unit-test platform as possible: the developer should be able to change facts easily, run and see the results in seconds. The tools used vary with the application: testing rules for a financial application might best use excel for constructing the fact input, whereas a deep structure might be easier via XML.
.