Share this page
Introducing Java Add-in Extensibility
Welcome to OpenText Functional Testing Java Add-in Extensibility.
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 OpenText Functional Testing Java Add-in.
About Java Add-in Extensibility
The OpenText Functional Testing Java Add-in provides built-in support for a number of commonly used Java objects. You use Java Add-in Extensibility to extend that support and enable recognition of additional Java controls. You can also use Java Add-in Extensibility to support recognizing a group of controls as one object. For example, if a search button and an edit box comprise a search box, and you want then to be seen as one functional unit.
When an object in the application is learned, it is recognized 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.
Java controls that are not supported out-of-the-box by the Java Add-in can be learned without using Extensibility. However, when unsupported Java control are learned, they are recognized as generic Java test objects. 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 is recognized 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 specify that a control or group of controls be recognized 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 can be recognized. This enables you to create tests that fully support the specific behavior of your custom Java controls.
Identifying the Building Blocks of Java Add-in Extensibility
The sections below describe the main elements that comprise OpenText Functional Testing object support: Test object classes, names, methods, and properties, as well as the ability to record events.
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.
Test Object Classes
In OpenText Functional Testing, 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. This mapping is used to determine which test object class to use for each object in the application.
When a control of an unsupported Java class (a custom class) is learned, the test object class used to represent the control is selected based on the class inheritance hierarchy. The closest supported ancestor of the class is located, and the test object class mapped to this class is used. For example, if the custom class extends java.awt.Applet, the control is recognized as a JavaApplet test object. If the custom class extends the java.awt.Canvas, the control is recognized as a JavaObject test object.
The icon that is used to represent this type of object, for example in the Keyword View and Object Repository, is also determined by the test object class.
Test Object Names
When an object is learned, data from the object is used 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 a control of an unsupported Java class is learned, and a test object class mapped to one of its ancestors is used, 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.
Test Object Identification Properties
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.
Test Object Methods
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.
Recording Events
One way to create GUI tests is by recording user operations on the application. When you start a recording session, OpenText Functional Testing listens for events that occur on objects in the application and registers corresponding test steps. Each Java object class defines which events OpenText Functional Testing can listen for. The Java Add-in determines what test step to record for each event that occurs.
Deciding When to Use Java Add-in Extensibility
The 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 an OpenText Functional Testing 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:
OpenText Functional Testing 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 generated 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 test objects for that Java class are named.
Individual sub-controls within your custom control might be identified, but your main control might not properly identified. 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. Individual controls contained in a wrapper object are not identified separately.
During a record session, when you perform operations or trigger events on your control, steps may not be recorded at all, or steps that are not specific to the control's behavior might be recorded. Alternatively, many steps might be recorded for an event that should be considered a single operation, or it a step might be recorded 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 support of a custom control, see Analyzing the Default Support and Extensibility Options for a Sample Custom Control.
Next steps:
