Open topic with navigation
The sections below describe the main elements that comprise UFT object support. These elements are the building blocks of Java Add-in Extensibility. By extending the existing support of one or more of these elements, you can create the support you need to create meaningful and maintainable tests.
In UFT, every object in an application is represented by a test object of a specific test object class. The Java Add-in maps each supported class to a specific test object class. UFT determines which test object class to use according to this mapping.
When UFT learns a control of a Java class that is not yet supported (a custom class), it selects the test object class to represent the control based on the class inheritance hierarchy. UFT searches for the closest ancestor of the class that is supported, and uses the test object class mapped to this class. For example, if the custom class extends java.awt.Applet, UFT recognizes the control as a JavaApplet test object. If the custom class extends the java.awt.Canvas, UFT recognizes the control as a JavaObject test object.
The icon that is used to represent this type of object in UFT, for example in the Keyword View and Object Repository, is also determined by the test object class.
When UFT learns an object, it uses data from the object to generate a name for the test object. A descriptive test object name enables you distinguish between test objects of the same class and makes it easier to identify them in your object repository and in tests.
When UFT learns a control of a Java class that is not yet supported and therefore uses a test object class mapped to one of its ancestors, the test object name is based on the rules defined for that test object class. In many cases, this is not the ideal name for the custom control.
The test object class that is mapped to the Java class determines the list of identification properties for a test object. It also determines which of these identification properties are used to uniquely identify the object, which identification properties are available for checkpoints (in the Checkpoint Properties dialog box), and which are selected by default for checkpoints. However, the actual values of the identification properties are derived from the definition of the custom class. Therefore, several custom classes that are mapped to the same test object may have different definitions for the same identification property.
The test object class that is mapped to the Java class determines the list of test object methods for a test object. However, the actual behavior of the test object method depends on the definition of the specific custom support class. This means that the same test object method may operate differently for different custom classes that are mapped to the same test object class.
One way to create UFT GUI tests is by recording user operations on the application. When you start a recording session, UFT listens for events that occur on objects in the application and registers corresponding test steps. Each Java object class defines which events UFT can listen for. The Java Add-in determines what test step to record for each event that occurs.