This chapter covers the following topics:
Unit testing enables you to review and make iterative changes while a configuration model is still in development. Perform unit testing to:
Review a configuration model and rules using the Model Debugger
View the Model structure in a UI before creating any configuration rules
Perform a final check before releasing the Model for testing by external users (for details, seeIntroduction to Publishing)
Test configuration rules in either the runtime Oracle Configurator or the Model Debugger to verify that they function as intended. It is good practice to test configuration rules incrementally. For example, if you receive an error in the runtime Oracle Configurator, you can temporarily disable one or more rules and then retest to determine which rule is causing the error. Then modify the rule in Configurator Developer to resolve the problem. Disabling rules is described in Enabling and Disabling Rules.
Before unit testing, be sure to generate logic. For details, see Logic Generation Status. Additionally, if you plan to test using a generated User Interface, you may need to refresh the UI. For details, see UI Refresh Status.
You unit test a configuration model from Configurator Developer by launching the Model Debugger, or a User Interface that you generated in Configurator Developer. You can access both unit testing environments from either Configurator Developer or the Oracle E-Business Suite Home page.
In Configurator Developer, you can unit test the Model that is open for editing by clicking the Test Model button in the Structure, Rules, or User Interface area of the Workbench. From the E-Business Suite Home page, launch a runtime UI or the Model Debugger by selecting Test Configuration from the main menu. In either case, you can enter session parameters before testing.
Session Parameters enable you to apply effectivity and specify a Model quantity when unit testing a configuration model in the Model Debugger or a runtime UI. When you enter an effective date, any Model structure that is not effective for the date or Usage that you specify does not appear, and any ineffective rules are ignored. If you do not want to hide nodes or disable rules based on effectivity, do not specify an effective date or a Usage.
Whether you are creating a new configuration or restoring an existing configuration, the default effective date is the system date (that is, the current date and time of the database on which Configurator Developer is running).
For an overview of effectivity, see Introduction to Effectivity.
Enter a Model Quantity if you want to see how ordering more than one Model affects the configuration. This setting affects the unit testing session only if the Model is a BOM Model, or it is a non-imported Model that references a BOM Model.
To be able to modify the value of any Totals and Resources in the Model Debugger, select Enable Editing of Totals and Resources. Selecting this option provides another way to test rules that use Totals and Resources as participants.
The Model Debugger provides a view of the Model’s hierarchical structure and allows you to test the structure and rules by selecting options, entering values, and adding component instances. You can also view a summary of your selections, save configurations, and restore saved configurations for additional testing.
The main benefit of using the Model Debugger is that a UI is not required to unit test a configuration model. The Model Debugger displays the entire Model structure, including non-BOM nodes, and provides different views of Model data based on your selections. You can also choose to test only specific areas of the Model, which may be time consuming in a UI if the Model is very large or if the UI is complex.
The Model Debugger displays each option’s logic state, indicates whether a component contains required selections, and enables you to run any associated Configurator Extensions. The Model Debugger runs in the same browser window as Configurator Developer.
Like a UI generated in Configurator Developer, the Model Debugger uses images to indicate the selection state and status of each option, and displays an "icon legend" on each page. However, unlike a generated UI, you cannot control which images are used in the Model Debugger. For important additional information regarding how options that are Logic False appear in the Model Debugger, see Displaying Logic False Options.
The images that the Model Debugger uses are shown in Default Selection State and Status Indicator Images.
To access the Model Debugger, you must log into Oracle Applications and select one of the predefined Oracle Configurator Developer responsibilities. For a description of these responsibilities, see the Oracle Configurator Implementation Guide.
For more information, see Unit Testing Using the Model Debugger.
When unit testing a generated User Interface, verify that the UI has the look and feel that you want for your runtime Oracle Configurator and the screens present appropriate information to the end user in an easily usable format.
View and test the structure of your Model and confirm that only the nodes and Properties you want the end user to see are visible. For details, see Configuring an Item in a Runtime Oracle Configurator.
As you test the Model, you may notice parts of the UI that you want to change or rules that do not function as you intended. Return to Configurator Developer to make any necessary changes. Before re-testing, be sure to regenerate logic and refresh the UI.
For more information on how Model structure and the User Interfaces you create in Configurator Developer are related, see Model Structure and Generated User Interfaces.
If you want to display pricing or Available to Promise (ATP) information in the UI, see Displaying Pricing Information and ATP Dates when Unit Testing.
For more information, see Unit Testing Using a Generated User Interface.
Note: Like other OA Framework-based applications, there is only one cache per Configurator Developer session. Therefore, if another user modifies a Template Reference in the UI that you are unit testing, the change appears at runtime when an action causes the page to be refreshed. For example, an Option Feature displayed as a group of radio buttons may change to a drop-down list at runtime when a Configurator Developer user changes the node’s Template Reference. When this occurs, Oracle Configurator does not display a message notifying the end user of the change.
Pricing information is available only for items that exist in the CZ schema’s Item Master (see Introduction to the CZ Schema). Depending on your implementation, this information may include list prices, selling prices, and the extended price. (The extended price is the quantity multiplied by the selling price.)
To display pricing or Available to Promise (ATP) information for items when unit testing using the Model Debugger or a generated UI, perform the following:
Enable pricing and ATP by setting the following profile options to Yes: .
CZ: Enable List Prices
CZ: Enable Selling Prices
CZ: Enable ATP
For more information, see the Oracle Configurator Installation Guide.
In the Configurator Developer Preferences page, specify the Oracle Configurator pricing and ATP callback interface packages and procedures to use.
For details, see Test Preferences.
After specifying the pricing and ATP callback interface packages and procedures, note the following before unit testing:
You must specify in the UI Definition whether prices and ATP information appears and what actions cause prices to be updated.
For more information, see Modifying the User Interface Definition.
The Model Debugger updates both list prices and selling prices whenever you make a selection or navigate to another page. There are no settings in Configurator Developer that allow you to modify this behavior.
For additional information about pricing and ATP, see the Oracle Configurator Implementation Guide.