Recall that a policy is the logical unit of deployment and can contain one or more rules. Also recall that policies are versioned and that deployed policies are immutable. Therefore, before you publish and deploy a policy, you need to test it.
Testing Policies by Implementing the IFactCreator Interface
As I've discussed, at run time, each of these facts and fact slots will be asserted into the BRE and the BRE will determine which rule(s) to add to its agenda based on the presence of facts. Therefore, even for testing purposes, you must provide the Business Rules Composer with a hydrated instance of the Customer object, which it will use to determine which rules should be added to the agenda. To hydrate an instance, you must first create what is called a "Fact Creator."
Creating a Fact Creator is straightforward. You simply need to implement the IFactCreator interface on a class to provide a surrogate Customer class to the BRE using a prescribed interface.
The CustomerFactCreator class (see Listing 5) shows the IFactCreator implementation. The CreateFacts method fulfills a contract to return an array of objects. The BRE uses these objects to conduct a pre-deployment test. In this case, I simply copied and pasted the Customer and PurchaseOrder initialization code from the unit test to the CreateFacts method, created a one-dimensional array to hold the Customer instance, and fulfilled the contract by returning the array.
With the Acme.BusinessEntities.dll in the GAC, right-click "Version 1.0" of the Customer Discounts Policy, and then select "Test Policy" as shown in Figure 20. A screen appears that lets you select the CustomerFactCreator. Click "Add," select the Acme.BusinessEntities.dll from the list of .NET assemblies, and then click "OK." The Business Rules Composer queries the selected assembly for any Fact Creators and enumerates them. As shown in Figure 21, select the CustomerFactCreator and click "OK."
Figure 20. Test Policy: The Business Rules Composer includes an integrated tool for testing condition behavior and agenda plan.
Figure 21. Fact Creator: You must supply a Fact Creator to the Business Rules Composer testing tool to assert the required facts for execution.
Now click "Test." Immediately, the testing tool displays the agenda results in the test output pane as shown in Figure 22.
Understanding Agendas and Priority
Here's a closer look at the Customer Discounts Policy test as shown in the agenda results in Figure 22.
|Figure 22. Test Results: The testing tool displays agenda results immediately following the assertion of test facts into the BRE.|
CustomerFactCreator asserted a Customer instance as a fact to the BRE. The BRE then looked for any rules containing conditions which map to fact slots present in the asserted fact (the Customer). Because the Customer indeed contains a field that indicates whether the sample customer is a preferred member, the BRE adds that rule to the agenda and executes it. The condition evaluated to true, because the PreferredMember fact slot on the Customer fact was set to true in your CustomerFactCreator. Because the Customer was asserted as a short-term fact, and there are no other rules in the policy, the BRE removes the Customer instance from memory and the execution cycle terminates.
If there are two or more rules that use the same fact slot in a condition, the BRE will determine execution order based on priority. You can set a priority on each rule within the Business Rule Composer. Rules with a higher priority fire first.
This has been a good way to test that the rule condition behaves as expected, and that the agenda is loading rules according to the expected priority, but you still don't know if the action works as designed. Unfortunately, there's no good way to do this within the Business Rules Composer. However, you'll find a unit test in your Visual Studio solution that is up to the job!