7.5 Testing Entity-Based View Objects Interactively

You test entity-based view objects interactively in the same way as read-only ones. Just add instances of the desired view objects to the data model of some application module, and then test that application module using the Business Components Browser.

7.5.1 Overview of Business Component Browser Functionality for an Updatable Data Model

You'll find the Business Components Browser tool invaluable in quickly testing and debugging your application modules. Figure 7-14 gives an overview of the operations that all of the Business Components Browser toolbar buttons perform.

Figure 7-14 Business Component Browser Functionality for Updatable Data Models

7.5.2 Adding View Object Instances to the Data Model

Following the same steps as you learned in Section 5.10.4.3, "How to Enable Active Master/Detail Coordination in the Data Model", add the following view object instances to the data model of the SRService application module to end up with the hierarchy of master/detail view objects shown in Figure 7-15:

• Select existing ServiceRequests view object instance in the Data Model tree first, then add a detail instance named ServiceHistories of the ServiceHistories view object that appears as a child of ServiceRequests in the Available list.

• Select existing StaffList view object instance in the Data Model tree first, then add a detail instance named AssignedServiceRequests of the ServiceRequests view object that appears as a child of StaffList in the Available list.

• Select the new AssignedServiceRequests view object instance in the Data Model tree first, then add a detail instance named AssignedServiceHistories of the ServiceHistories view object that appears as a child of ServiceRequests in the Available list.

Figure 7-15 Business Components Browser Showing Editable Results of an Entity-Based View Object

7.5.3 How to Test Entity-Based View Objects Interactively

Assuming that you've set up the SRService application module's data model as shown in Figure 7-15, to test it do the following:

To test entity-based view objects:

1. Select the application module in the Application Navigator and choose Test... from the context menu.

2. Click Connect on the Business Components Browser Connect dialog to use the default SRServiceLocal configuration for testing.

Note: By default, an application module has only its default, local configuration, named AppModuleNameLocal. If you have created additional configurations for your application module and want to test it using one of those instead, just select the desired configuration from the Business Components Configuration dropdown list on the Connect dialog before clicking Connect.

7.5.4 What Happens When You Test Entity-Based View Objects Interactively

When you launch the Business Components Browser, JDeveloper starts the tester tool in a separate process and the Business Component Browser appears. As shown in Figure 7-16 the tree at the left of the display shows the hierarchy of the view object instances in the data model, and includes additional nodes between a master view object instance and a detail view object instance that represent the view link instance that performs the active master/detail coordination as the current row changes in the master.

Figure 7-16 SRService Data Model in the Business Components Tester

Double-clicking on the HistoryLinesForRequest2 view link instance in the tree executes the master objects — if it has not been executed so far in the testing session — and displays the master/detail tester panel shown in Figure 7-17. Additional context menu items on the view object node allow you to reexecute the query if needed, remove the tester panel, and perform other tasks. You saw a similar master/detail panel when you used the Business Components Browser in Section 5.5, "Testing View Objects Using the Business Components Browser". You can see and scroll through the query results. One important difference is a direct result of using an entity-based view object this time. Instead of seeing disabled UI controls showing read-only data, you now see editable fields and are free to experiment with creating, inserting, updating, validating, committing and rolling back.

Figure 7-17 Instances of Entity-Based View Objects are Fully Editable by the Tester

Try experimenting with the multiple levels of master/detail hierarchies, opening multiple tester panels at the same time, and using the Display Results in a Window toolbar button to "pop" a tab out of the frame into a separate window to see multiple view object's data at the same time.

7.5.5 Simulating End-User Interaction with Your Application Module Data Model

Using the Business Components Browser, you can simulate an end user interacting with your application module data model before you have started to build any custom user interface of your own. Even after you have your UI pages constructed, you will come to appreciate using the Business Components Browser to assist in diagnosing problems when they arise. You can reproduce the issues in the Business Components Browser to discover if the issue lies in the view or controller layers of the application, or is instead a problem in the business service layer application module itself.

Using just the master/detail tester page shown in Figure 7-17, you can test several functional areas of your application.

7.5.5.1 Testing Master/Detail Coordination

Use the navigation buttons on the toolbar, you can see that the service history rows for the current service request are correctly co-ordinated.

7.5.5.2 Testing UI Control Hints

The prompts displayed in the testing panels help you see whether you have correctly defined a user-friendly Label Text control hint for each attribute. For example, the RequestDate attribute in the ServiceRequests view object instance has the prompt Requested On. Hovering your mouse over the edit field for the RequestDate field, you'll shortly see the Tooltip control hint text appear if you've defined it. The tooltip that appears says, "The date on which the service request was created", which is how you set up the hint on your entity object back in Section 6.5.1, "How to Add Attribute Control Hints". Since you didn't specifically define any new control hints for the ServiceRequests view object, this illustrates that the entity-based view object attributes inherit their control hints from those on the underlying entity object attribute.

7.5.5.3 Testing View Objects That Reference Entity Usages

By scrolling through the data — or using Specify View Criteria toolbar button to search — you can verify whether service requests that have not yet been assigned are correctly displaying. If you correctly altered the query's WHERE clause to use an outer join, these row will appear as expected.

By changing the AssignedTo attribute to a different technician's user ID — double-click on the StaffList view object instance in the Business Components Browser to browse for some valid staff user ID's — you can verify that the corresponding reference information is automatically updated to reflect the new technician.

By observing the values of the ProductName field and the two Email Address fields in some example rows of the ServiceRequests, you can see the corresponding user-friendly product name, and the email addresses of both the customer who created the request, and the technician to whom it is assigned. You can also notice a problem that both the customer's email address and the technician's email address are inheriting the Label Text hint from the User entity object of Email Address. It won't be clear to the end user which email address is which.

To remedy the situation where both the technician's email address and the customer's email address display with the same, inherited Email Address label, edit the ServiceRequests view object and define a Label Text control hint for both at the view object level. Set the Label Text hint to Technician Email Address for the TechnicianEmail attribute and Customer Email Address for the CustomerEmail attribute. Use the Business Components Browser to verify that these control hints defined at the view object level override the ones it would normally inherit from the underlying entity object.

7.5.5.4 Testing Business Domain Layer Validation

Try to change the Status attribute value of a Closed service request to have a value of Reopened. When you try to tab out of the field, you'll get an exception:

(oracle.jbo.AttrSetValException) The status must be Open, Pending, or Closed

Based on the other simple declarative validation rules defined in Section 6.7, "Using Declarative Validation Rules", you can try to update a ProblemDescription value to contain the word urgent surrounded by spaces, to receive the error:

(oracle.jbo.AttrSetValException)
Problem Description cannot contain the word urgent

Lastly, you can try to enter a ProdId value of 1234 to violate the range validation rule and see:

(oracle.jbo.AttrSetValException) Valid product codes are between 100 and 999

Click on the rollback button in the toolbar to revert data to the previous state.

7.5.5.5 Testing Alternate Language Message Bundles and Control Hints

By opening the Properties tab on the Connect dialog when you launch the Business Components Browser, you can override the default locale settings to change:

• jbo.default.country = IT

• jbo.default.language = it

With these properties set, you can see whether the Italian language translations of the ServiceRequest entity object control hints are correctly located. You'll notice Stato, Aperto Il, and Problema labels instead of Status, Requested On, and Problem (among others). You also will see that the format of RequestDate changes from a value like 03/12/2006 16:55 to 12/03/2006 16:55.

7.5.5.6 Testing Row Creation and Default Value Generation

Click on the Create Row button in the toolbar for the ServiceRequests view object instance to create a new blank row. Any fields that have a declarative default value will appear with that value in the blank row. The DBSequence-valued SvrId attribute appears read-only in the new row with its temporary negative number. After entering all the required fields — try 100 for the ProdId and 300 for the Requested By field — click on the commit button to commit the transaction. The actual, trigger-assigned primary key appears in the SvrId field after successful commit.

7.5.5.7 Testing New Detail Rows Have Correct Foreign Keys

If you try adding a new service history row to an existing service request, you'll notice that the view link automatically ensures the foreign key attribute value for SvrId in the new ServiceHistories row is set to the value of the current master service request row.