Analyzing the Default UFT Support and Extensibility Options for a Sample Custom Control

The following example illustrates how you can use Java Add-in Extensibility to improve the UFT support of a custom control.

The AllLights control shown below is a game application that is not specifically supported on UFT.

This application operates as follows:

If you point to this control using the Object Spy, UFT recognizes it as a generic JavaApplet named AllLights (the name of the custom class). The icon shown is the standard JavaApplet class icon.

If you record on the AllLights control without implementing support for it, the Keyword View looks like this:

In the Editor, the recorded test looks like this:

Note that only generic Click steps are recorded, with arguments indicating the low-level recording details (x- and y-coordinates and the mouse button that performed the click). These steps are difficult to understand and modify.

If you use Java Add-in Extensibility to support the AllLights control, the result is more meaningful. UFT recognizes the control as an AllLights test object named Lights and uses a customized icon. The identification properties include relevant information, such as oncount and onlist, which provide the total number of all lights that are on at a given moment and their ordinal locations in the grid.

When you are ready to create a test on the control, the ClickLight and Restart methods are supported. These methods can be recorded or you can select them manually in the Operation column of the Keyword View. You can also create a checkpoint to check the value of identification properties, for example, gameover (that indicates whether all lights are on, meaning that you won the game).

In the Keyword View, a test may look like this:

In the Editor, the test looks like this:

This test is easier to understand and modify.