|Maintenance Notice - PDF Generation|
|Dynamic PDF generation for web-based content is temporarily unavailable. This maintenance affects dynamic PDF files that are generated from either the HTML-based page or manual that you are viewing. Links that normally allow this functionality have been hidden, and will reappear as soon as the feature is restored.
Supporting Building Test Scenarios
To support building test scenarios, the rule developer should provide a mapping between the parameters (which the rule author is familiar with) and the underlying fact model. In this way, when the rule author provides a sample value for say, orderValue, GRAT will know how to build the appropriate Fact object to run the test.
In this case, it would create a Customer fact and set the order field to the specified value. For this example, we will map the parameters to the Fact model in the following way:
- customerSegment -> Customer.segment
- orderValue -> Customer.order
- specialOffer -> Customer.offer
In GRDT, right-click on each parameter and choose Associate Property. Then choose the appropriate Fact and field from the pop-up window.
Mapping Parameters Window
Navigate to the Test Scenarios tab and create a test scenario to test our decision table rule at the Finance Department node. Select test values customerSegment and orderValue from the Add Given drop-down. Then select specialOffer from the Add Expectation drop-down.
Now, insert rows of data. In these rows you can put some test values and also choose what your predicted or expected result should be.
When you click on the Run Test Scenario button, these test values will be passed into the rule package and the result will be compared to your expectations. If they match, you will see a green check mark in the Results column.
Note that we purposely passed in data that we predicted would return a positive result (for example, the customer gets the special offer) as well as a negative result (for example, the customer does not qualify). These test scenarios are then saved and can be executed in the future when rules are added or modified.
Note, the 4th row of the table, shows our Bronze customer with an order value of 9000 NOT receiving a special offer. This is because the test was run against the Finance Department node of the hierarchy. In our example, we added a linear rule to the Accounts Payable department which addresses the Bronze customer.
We can now create a new test scenario which targets the Accounts Payable department and validates that, in this case, the Bronze customer gets an offer. In our new test scenario (TS-116), we set the Business Hierarchy to the Finance Department > Accounts Payable department. We copy the same test data and when we run it, notice that the Bronze customer shows an unsuccessful result when our expectation is that they do NOT receive an offer.
We simply adjust the test scenario so that we now expect an offer for this customer by checking the specialOffer box. We now get a successful result when running the test.