Testing and Validating Business Rules

7.1 Overview

The business rules test feature enables both developers and business users to quickly check that a rule satisfies the expected behavior or, if modified, to see if a rule regresses existing functionality.

You can author and test rules at design-time in Oracle JDeveloper or Business Process Composer. At runtime, you can test rules in SOA Composer.

You can write tests declaratively, with no need for knowledge of XML or prior rules actions or programming languages such as Java. Additionally, tests support all types of facts (XML, Java, RL, and ADF-BC) and can be run on SOA or non-SOA use cases.

The test feature provides test reports with diagnostic comments and visual differences between the expected and actual values that can be used to correct the rules or fix the tests.

Figure 7-1 shows the UI in JDeveloper. For more information about using JDeveloper, see Introduction to Oracle JDeveloper in Oracle Fusion Middleware Developing Applications with Oracle JDeveloper.

Figure 7-1 Test Tab in JDeveloper

Description of "Figure 7-1 Test Tab in JDeveloper"

7.1.1 Components of the Test Feature

No matter which UI you use, the testing functionality behaves mostly the same way in JDeveloper, BP Composer, and SOA Composer.

Decision functions must have been already created before you begin--there is a one to one mapping between decision functions and tests. Once a decision function is associated with a test suite or test template, it cannot be changed later.

The components of the test feature are:

Test Suites and Test Cases

You can create a test suite with one or more test cases. You can also create templates that serve as templates for creating other test cases.
Test Templates

Test templates enable you to create similar test cases that differ only by the values of a few Fact properties. Templates also let you execute ad-hoc tests by specifying values for parameters. Ad-hoc tests enable you to perform sanity tests and try different value combinations for specific parameters before creating them as test cases in a test suite.
Test Execution

Executing test suites or test cases invokes the decision function and executes the rulesets defined in the decision function and presents the results in a new tab, as shown in Figure 7-2. Tests are executed via RL generation.

Figure 7-2 Test Results Tab

Description of "Figure 7-2 Test Results Tab"

Keep the following in mind:
- Tests can be executed either from the Test tab of the Dictionary or from the Decision Functions tab.
- Tests can be defined in the current dictionary for decision functions in linked dictionaries.
- Tests defined in linked dictionaries can be executed in the current dictionary. Tests from linked dictionaries are available as read-only for execution.
- If you modify the inputs/outputs in a decision function, the changes are automatically synced to the tests you have defined. Tests are synced to fact-types referenced in the tests. If you remove facts from a decision function, the test feature enables you to delete those facts from the input/output tree of the test.
- A Fact is an instance of a FactType that defines the Test Data and has property values corresponding to each of the FactType properties. If a Property value is a complex data type, it is defined using Fact instances as well.

7.2 Testing Rules in JDeveloper

You can test your rules as you design them in JDeveloper.

In the Test Case editor, you define the inputs and expected output values for a Test Case. The values here can be simple values or expressions that use globals, functions, and so on.

The input and output Fact trees are auto-initialized based on the inputs/outputs specified for the Decision Function.

The test input and output Fact trees are also auto-synchronized with any changes to the Decision Function (if you add, delete, modify inputs or outputs) or fact types (if you add, delete or modify properties). The auto-synchronization flags and highlights invalid Facts or Property values that were changed in a Decision Function or Fact type. These flags in the test input/output help you to identify and fix issues in your test definitions.

Testing Permission Related Cases

Before testing permission related cases, change the refresh time 10 seconds. This is an important prerequisite for reliable test results.

To change the refresh time to 10 seconds:

Navigate to $MW_HOME/user_projects/domains/soainfra/config/fmwconfig.
Open jps-config.xml.

Set oracle.security.jps.ldap.policystore.refresh.interval to 10000.

<serviceInstance name="pdp.service" provider="pdp.service.provider">
	<property name="oracle.security.jps.ldap.policystore.refresh.interval" value="10000"/>
</serviceInstance>

Restart the server.

7.2.1 How to Create and Manage Test Suites and Cases

You can create a test suite with one or more test cases. Test suites can only be defined for specific decision functions.

For more information about decision functions, see Working with Decision Functions.

For detailed documentation of fields and other UI controls, click Help from within JDeveloper.

Figure 7-3 Test Tab in JDeveloper

Description of "Figure 7-3 Test Tab in JDeveloper"

To create a test suite:

In Rules Designer, click the Test tab.
Click the Test Component drop down and select a Test Model from the list.
Click + to create a new test case for the test suite.
Enter a name, choose a Decision Function, enter a Description.
Click OK. The test suite is displayed.
Click Edit to review the Input and Output documents for the test case. This is where you can edit values to specify the input and the expected output, as shown in Figure 7-4:

Figure 7-4 Inputs and Outputs

Description of "Figure 7-4 Inputs and Outputs"
Check the Unfired Rules are Errors check box if unfired rules are treated as errors from the execution.
Click the Draft Test check box to turn off the test validation.

When you have finished creating test suites and cases, you can run them. For more information, see How to Run Test Suites or Cases.

7.2.2 How to Create Test Templates

Test templates enable you to reuse input and output values to repeat tests on those fields and values.

For detailed documentation of fields and other UI controls, click Help from within JDeveloper.

To create a test template:

In Rules Designer, click the Test tab.
Click the Test Component drop down and select the Test Model/Templates from the list.
Go to the Templates table and click + to create a new test template.
Enter a name, choose a Decision Function, enter a Description.
Click OK. The test template is displayed, where you can see the Input and Output documents. This is where you can edit values to specify the input and the expected output, as shown in Figure 7-5.

Figure 7-5 Test Template

Description of "Figure 7-5 Test Template"

When you have finished setting up your test templates, you can run them. For more information, see How to Run Ad-hoc Tests from Test Templates.

7.2.3 How to Run Test Suites or Cases

When you run a test, a new tab is opened, and you can see the diagnostic comments, exceptions, and test results. Tests can be run either as a suite, multiple test cases, or as individual test cases.

For detailed documentation of fields and other UI controls, click Help from within JDeveloper.

To run a test suite or case:

Select a Test Suite or Test Case to run, and click Execute.
A new tab opens. A new tab Results opens. Click it to see the test results.

For test suite execution, the tab shows a summary of the test results by default, but you can double-click each test case to see its test results. For test case execution, the tab shows the test results.

If a test fails, the test results will show diagnostic comments and output differences or exceptions depending on the cause of the failure.

The execute button is enabled only when a test suite or test case (or test template) is selected from the table and as long as there are no validation warnings in the current dictionary.

7.2.4 How to Run Ad-hoc Tests from Test Templates

This is where you can run ad-hoc tests from templates by editing the nodes in input and output trees. The inputs and outputs are from the decision function.

For detailed documentation of fields and other UI controls, click Help from within JDeveloper.

To run ad-hoc tests from test templates:

Go to the Templates table and select a test template. The inputs and outputs fields are displayed, as shown in Figure 7-6.

Figure 7-6 Template Inputs and Outputs

Description of "Figure 7-6 Template Inputs and Outputs"
Enter values for variable or parameter fields and click Run. The Ad-Hoc Test dialog is displayed.
Select the appropriate options:
- Check the Unfired Rules Are Errors check box if unfired rules are treated as errors from the execution.
- Click List View or Tree View to toggle between the views.
- Check the Constant check box and select a constant from the list.
- Check the Mark as Parameter check box for variable fields of the test template. Values for variable fields are entered when the template is consumed like when the template is tested or used to create a test case.
Click Execute Test to run the template.
From the new Results tab, check the test results.

7.2.5 How to Run Tests for a Specific Decision Function

You can run tests from the Decision Function tab. This view only shows you the Test Suites and Test Cases for the specific Decision Function.

For detailed documentation of fields and other UI controls, click Help from within JDeveloper.

To run tests for a specific decision function:

In Rules Designer, click the Decision Functions tab.
Click to select a test case and click the Test button.
The Decision Function Test Editor dialog appears. This dialog is just another view of the testing feature.

7.3 Testing Rules in Business Process Composer

You can test your rules as you design them in Business Process Composer.

For more information about using Business Process Composer, see Introduction to Oracle Business Process Composer in Oracle Fusion Middleware Developing Business Processes with Oracle Business Process Composer.

7.4 Testing Rules in SOA Composer

At runtime, you can use SOA Composer to regression test rules. This enables business users to quickly check if a modified rule changes the existing functionality.

Figure 7-7 shows the Tests tab in SOA Composer. The Tests tab only appears if you have a deployed composite and are in a SOA Composer session. Click Create Session to open a session.

Figure 7-7 Tests Tab in SOA Composer

Description of "Figure 7-7 Tests Tab in SOA Composer"

7.4.1 How to Create and Manage Test Suites and Cases

You can create a test suite with one or more test cases. Test suites can only be defined for specific decision functions.

For more information about decision functions, see Working with Decision Functions.

Figure 7-8 Test Suite Page

Description of "Figure 7-8 Test Suite Page"

For detailed documentation of fields and other UI controls, click Help, Help for This Page from within SOA Composer.

To manage test suites and cases:

In Rules Designer, click the Tests tab and click in a Test Suite row to enable the action buttons.

Click the Draft Tests check box if you want to turn off test validation.
Click + to create a new Test Suite.
Enter a Name and Description, then choose a Decision Function.
The test suite is displayed.
After creating a test suite, if you want to create test cases, click the test suite in the Test Model tree and click + to create a Test Case or a Test Case from Templates.
You can Save Changes in Current Tab to save data at any time or click Publish if you are done with changes.
You can also click a test case in the Test Model tree to see the Input and Output documents for the test case. This is where you can edit values to specify the input and the expected output, as shown in Figure 7-9.

Figure 7-9 Inputs and Outputs from Decision Functions

Description of "Figure 7-9 Inputs and Outputs from Decision Functions"

In the Test Case editor, you define the inputs and expected output values for a Test Case. The values here can be simple values or expressions that use globals, functions, and so on.

The test input and output Fact trees are auto-initialized based on the inputs and outputs specified for the Decision Function.

The input and output Fact trees are also auto-synchronized with any changes to the Decision Function (if you add, delete, modify inputs or outputs) or fact types (if you add, delete or modify properties). The auto-synchronization flags and highlights invalid Facts or Property values that were changed in a Decision Function or Fact type. These flags in the test input/output help you to identify and fix issues in your test definitions.
Click Edit to make all of the nodes in the tree editable.
If you edit a field in the tree, click Show Values to show only those values.
Check the Flag Rules not Firing as Error check box if unfired rules are treated as errors from the execution.

When you have finished setting up your test suites and cases, you can run them. For more information, see How to Run Test Suites or Cases.

7.4.2 How to Create Test Templates

Test templates enable you to reuse input and output values to repeat tests on those fields and values.

For detailed documentation of fields and other UI controls, click Help, Help for This Page from within SOA Composer.

To create test templates:

In Rules Designer, click the Tests tab.
Click Test Model in the navigation tree. In the Test Templates region, click + to create a new test template.
Enter a Name, Description, and choose a Decision Function.
Click Save.

To run ad-hoc tests from test templates, see How to Run Ad-hoc Tests from Test Templates.

7.4.3 How to Run Test Suites or Cases

When you run a test, a new tab is opened, and you can see the diagnostic comments, exceptions and test results. Tests can be run either as a suite, multiple test cases or as individual test cases. Tests are executed via RL generation.

For detailed documentation of fields and other UI controls, click Help, Help for This Page from within SOA Composer.

To run test suites or cases:

Select a Test Suite or Test Template to run, and click Execute.

The execute button is enabled only when a test suite or test case (or test template) is selected from the table and as long as there are no validation warnings in the current dictionary.
A new tab, Results appears. Click it to see the test results.

For test suite execution, the tab shows a summary of the test results by default, but you can double-click each test case to see its test results. For test case execution, the tab shows the test results.

If a test fails, the test results will show diagnostic comments and output differences or exceptions depending on the cause of the failure.

Figure 7-10 Diagnostic Comments for a Test Suite

Description of "Figure 7-10 Diagnostic Comments for a Test Suite"

If you select a test suite from the Test Model tree and run it, you can see the Decision Trace tab, as shown in Figure 7-11.

Figure 7-11 Decision Trace UI

Description of "Figure 7-11 Decision Trace UI"

7.4.4 How to Run Ad-hoc Tests from Test Templates

The Input and Output trees are loaded with input and output facts from the associated Decision Function, as shown in Figure 7-12. If you modify facts in a Decision Function, those changes are automatically synced to the Input and Output facts.

Figure 7-12 Input and Output Facts

Description of "Figure 7-12 Input and Output Facts"

For detailed documentation of fields and other UI controls, click Help, Help for This Page from within SOA Composer.

To run ad-hoc tests from test templates:

To see the Input and Output facts, click to choose a template from the Test Model tree.

This is where you can edit values to compare the input with the expected output. You can add dynamic values here or check Mark as Parameter to be able to enter values when the rule is executed.

For more information about how to use the Expression Builder, see Working with Tree Mode Rules.
Click the Execute Test Template button to run the template. A dialog box appears.
Enter values for those variable or parameter fields and click Run from the dialog.
From the new Results tab, check the test results. Click the Decision Trace tab to see the audit trail.

7.4.5 How to Run Tests for a Specific Decision Function

You can run tests for specific Decision Functions, as shown in Figure 7-13:

Figure 7-13 Decision Functions Tab

Description of "Figure 7-13 Decision Functions Tab"

For detailed documentation of fields and other UI controls, click Help from within JDeveloper.

To run tests for a specific Decision Function:

Click the Decision Functions tab and select the appropriate Decision Function from the list.
In the Tests field, use the dropdown to select the appropriate test.
The test is opened in the Tests tab. Click the test, and then click Execute to run your test.
The results tab appears. Click the new tab to view test results.

7.5 Testing Decision Functions Using a Rules Function

You can test rulesets by creating a decision function and calling the decision function from Rules Designer with an Oracle Business Rules function.

In the body of the Oracle Business Rules function you create input facts, call a decision function, and validate the facts output from the decision function. For more information, see Introduction to Decision Functions and Introduction to Oracle Business Rules Functions.

To test a decision function using an Oracle Business Rules function:

Confirm that your dictionary is valid.

For more information on dictionary validation, see How to Validate a Dictionary
In Rules Designer, select the Functions navigation tab.
In the Functions area click the Create... button.
Enter the function name in the Name field, or use the default name.
Select the return type from the Return Type list.

For a test function, select boolean.
In the Arguments table, confirm that there are no arguments. For a test function, you cannot specify any arguments.
In the Body area, enter the test function body.
In the body of the test function you can call a decision function using assign new to call and get the return value of the decision function (in the body of the test function you create input facts, call a decision function, and validate the facts output from the decision function).

A decision function call returns a List. Thus, to test a decision function in a test function you do the following:
- You create the input data as required for the decision function input arguments.
- You call the decision function with the arguments you create in the test function.
- You place results in a List, for example, in the following:
```
assign new List resultsList = DecisionFunction_1(testScore)
```
Select the function and click the Test Function button.

The function is executed. The output is shown in a Function Test Result dialog.
Click OK to dismiss the Function Test Result dialog.

7.5.1 What You Need to Know About Testing Decision Functions

You can use Oracle Business Rules Functions to test decision functions from within Rules Designer. Keep the following points in mind when using a test function:

The Test Function button is gray if the dictionary associated with the test Oracle Business Rules Function contains any validation warnings. The Test Function button is only shown when the dictionary validates without warnings.
To enable logging you can call RL.watch.all(). For more information on RL Language functions, see Rules Language Reference for Oracle Business Process Management. In this guide, RL.watch.all() is an alias for the RL Language function watchAll().
As an alternative to the example above, you can enter the function body that is shown in the example below:
```
call RL.watch.all()
assign new TestScore testScore = new TestScore()
modify (testScore, name: "Bill Reynolds", testName: "Math Test", testScore: 81)
assign new TestGrade testGrade = (TestGrade)DecisionFunction_1(testScore).get(0)
return testGrade.grade == Grade.B
```
For the testScore value 81, this function returns Test Passed. For the testScore value 91, this returns Test Failed.

This function runs and shows the RL.watch.all() output. The dialog shows Test Passed when the grade is in the B range. The dialog shows Test Failed when the grade asserted is not in the B range.

7.6 Testing Decision Services in SOA Composites

In a BPM or SOA application that uses Oracle Business Rules with a Decision Service, you can test rules at runtime with Oracle Enterprise Manager Fusion Middleware Control Console Test Web Service page, where you can create an instance of your composite for testing.

For more information about how to create a test instance of your composite after you have finished designing and deploying it, see Initiating a SOA Composite Application Test Instance in Oracle Fusion Middleware Administrating Oracle SOA Suite and Oracle Business Process Management Suite.

You can see the audit trail for the Decision Service execution. For more information, see Monitoring Business Rule Tracing in Oracle Fusion Middleware Administrating Oracle SOA Suite and Oracle Business Process Management Suite.