The Business Rule Engine, aka BRE, has been extensively used by organizations since its introduction on the BizTalk Server 2004.

As a mechanism for composing and executing business rules, the BRE was conceived to allow Business Analysts to author and manage their own rules without extensive technical background.

Regardless of who is creating and maintaining the rules, logic is being generated and should be submitted to tests as rigorous as the ones applied to any algorithm. The mechanic is the same, inputs are known and for each rule an universe of output can be assumed.

It is possible to create unit tests by hand using the BRE Library (Microsoft.RuleEngine), however, this process can become time consuming depending on the number of rules you have to test and maintain.

Alternatively, creating a new BizUnit step that could unit test BRE rules and also take advantage of all the existent BizUnit Steps to validade the results sounded as a plausible solution for me.

The idea is pretty simple: Submit a document as a fact to the BRE and validate the results.

Right, but I have several rules that accept different kinds of facts other than documents as input, for example .Net Types, how would this BizUnit Step fill this requirement?

BizUnit Context Loaders could be used to handle those cases, basically the BRE BizUnit step would search for additional facts in the BizUnit Context, which would allow complete customization of incoming facts.

The BizTalk ESB Tookit 2.0 allows using the BRE as a dynamic mechanism of itinerary, mapping and endpoint resolution. I believe this will leverage even more the BRE popularity and increase drastically the need of having effective testing tools.

The Toolkit executes the mentioned resolution by evaluating the properties of a known data structure, technically named as “Resolution”. This data structured is firstly handed to the chosen “Resolvers” which execute their logic and fill the “Resolution” object properties as result of the resolution process.

If I am using the BRE as a “Resolver”, and I intend to create several rules to execute the dynamic resolution logic, how could I create a unit test to verify if the resolution is being executed correctly based on the inputs provided?

First, I need to be able to not only send a document as an input fact to the BRE but also the mentioned “Resolution” data structure, and secondly, the resultant data structure has to be validated to identify if the properties were properly filled as expected.

Thats where the ESBToolkitResolutionContextLoader and ESBToolkitResolutionValidationStep come in, they both fill the gap to accomplish ESB BRE Resolution unit tests using BizUnit steps.

The ESBToolkitResolutionContextLoader is responsible to load the “Resolution” data structure into the BizUnit Context, whereas ESBToolkitResolutionValidationStep will validate the same structure after the resolution process.

Notice that although these two steps are being mentioned in a BRE Resolution context, they are completely disconnected from BRE and could be reused to evaluate results of any other ESB Resolver (say that somebody creates a UDDI Resolver BizUnit Step for example).

See the "Documentation" section for more information on how to configure the mentioned BizUnit Steps.

The Blog Post http://whiteboardworks.com/2010/03/unit-testing-biztalk-business-rule-engine/ (Unit Testing Biztalk Business Rule Engine) also provide additional information.

Last edited Mar 30, 2010 at 10:38 PM by brunospinelli, version 10