While building rules, having the ability to see them run and evaluate if what they are doing is what they were designed to do is important. However, one of the problems that can happen in any set of business rules – whether built graphically in a tool like the Decisions rule designer, or coded by programmers – is a rule is fundamentally changed or even broken without anyone being able to catch it.

In the software development world most methodologies now involve not just writing a piece of code but also writing (in code) a battery of tests that allow a system to be excersized and validated automatically. The advantage of this is when behavior is broken or changed, the test execution tool can catch this and it can be dealt with.

In a graphical environment there is the need to this same type of testing.

• Is this rule still producing the results I am expecting? 
• Does this rule handle bad input as it was designed to do?
• Does this rule fail when it it supposed to? (yes, a rule failing might be what it is supposed to do, in the case of missing data etc)

The decisions platform includes a unit test framework that allows tests to be created and executed in a graphical environment.

Every test includes:

• Name
• Inputs to the rule or flow
• Expected result (expected to return a value? expected to fail? expected to run without failure?)

Would you like to see a demo of how you can unit test rules within the Decisions platform? Drop us a line here. 

(We are joining Technorati!) TS49VQ5YCSA2