Introducing UFT One Java Add-in Extensibility

Welcome to UFT One Java Add-in Extensibility.

UFT One Java Add-in Extensibility enables you to provide high-level support for third-party and custom Java controls that are not supported out-of-the-box by the UFT One Java Add-in.

About UFT One Java Add-in Extensibility

The UFT One Java Add-in provides built-in support for a number of commonly used Java objects. You use UFT One Java Add-in Extensibility to extend that support and enable UFT One to recognize additional Java controls. You can also use Java Add-in Extensibility to teach UFT One to recognize a group of controls as one object. For example, if a search button and an edit box comprise a search box, and you want UFT One to see them as one functional unit.

When UFT One learns an object in the application, it recognizes the control as belonging to a specific test object class. This determines the identification properties and test object methods of the test object that represents the application's object in UFT One.

UFT One can learn Java controls that are not supported out-of-the-box by the Java Add-in without using Extensibility. However, when UFT One learns a Java control that is not supported, it recognizes the control as a generic Java test object. This type of Java test object might not have certain characteristics that are specific to the Java control. Therefore, when you try to create test steps with this test object, the available identification properties and test object methods might not be sufficient.

For example, consider a custom control that is a special type of button that UFT One recognizes as a plain JavaObject. JavaObject test objects do not support simple Click operations. The JavaObject.Click method requires the coordinates of the click as arguments. To create a test step that clicks this custom control, you would have to calculate the button's location and provide the coordinates for the click.

Alternatively, consider a search box where pressing the search button searches for a string entered in the adjacent edit box. You would want to replace the button's Click operation with a more functional Search operation that uses text from another control.

By creating support for a Java control using Java Add-in Extensibility, you can direct UFT One to recognize the control or group of controls as belonging to a specific test object class, and you can specify the behavior of the test object. You can also extend the list of available test object classes that UFT One is able to recognize. This enables you to create tests that fully support the specific behavior of your custom Java controls.

Back to top

Identifying the Building Blocks of Java Add-in Extensibility

The sections below describe the main elements that comprise UFT One 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 One, 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 One determines which test object class to use according to this mapping.

When UFT One 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 One 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 One recognizes the control as a JavaApplet test object. If the custom class extends the java.awt.Canvas, UFT One recognizes the control as a JavaObject test object.

The icon that is used to represent this type of object in UFT One, for example in the Keyword View and Object Repository, is also determined by the test object class.

When UFT One 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 One 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 OneGUI tests is by recording user operations on the application. When you start a recording session, UFT One listens for events that occur on objects in the application and registers corresponding test steps. Each Java object class defines which events UFT One can listen for. The Java Add-in determines what test step to record for each event that occurs.

Back to top

Deciding When to Use Java Add-in Extensibility

The UFT One Java Add-in provides a certain level of support for every Java control. Before you extend support for a custom Java control, analyze it from a UFT One perspective to view the extent of this support and to decide which elements of support you need to modify.

When you analyze the custom control, use the Object Spy, Keyword View, Editor, and the Record option. Make sure you examine each of the elements described in .

If you are not satisfied with the existing object identification or behavior, your control is a candidate for Java Add-in Extensibility, as illustrated in the following situations:

  • UFT One might recognize the control using a test object class that does not fit your needs. You can use Java Add-in Extensibility to map the custom class to another existing test object class or to a new test object class that you create.

  • The test object class mapped to the control might be satisfactory, but you would like to customize the behavior of certain test object methods or identification properties. You can use Java Add-in Extensibility to override the default implementation of these properties and methods with your own custom implementation.

  • You may find that the test object names UFT One generates for all controls of a certain Java class are identical (except for a unique counter) or that the name used for the control does not clearly indicate the object it represents. You can use Java Add-in Extensibility to modify how UFT One names test objects for that Java class.

  • UFT One may identify individual sub-controls within your custom control, but not properly identify your main control. For example, if your main custom control is a digital clock with edit boxes containing the hour and minute digits, you might want changes in the time to be recognized as SetTime operations on the clock control and not as Set operations on the edit boxes. You can use Java Add-in Extensibility to treat a custom control as a wrapper object for the controls it contains. UFT One does not learn the individual controls contained in a wrapper object.

  • During a record session, when you perform operations or trigger events on your control, UFT One may not record a step at all, or it may record steps that are not specific to the control's behavior. Alternatively, UFT One may record many steps for an event that should be considered a single operation, or it may record a step when no step should be recorded. You can use Java Add-in Extensibility to modify the events to listen for and the test steps to record for specific events.

For an example illustrating how to use Java Add-in Extensibility to improve UFT One support of a custom control, see Analyzing the Default UFT One Support and Extensibility Options for a Sample Custom Control.

Back to top

Next steps: