Supporting Identification Properties

The identification properties of a custom control are defined in the test object class. This can be an existing UFT One test object class or one you define in a test object configuration file.

Support for the identification properties is provided in the support class by implementing a method with the following signature for each identification property:

public String <identification property name>_attr(Object obj)

The method name must contain only lowercase letters (even if the property name in the test object configuration file contains uppercase letters). The obj argument is the object that represents the custom control.

Within the method, you return the value of the required property by using the custom class's public members. (Note that the support class can access only those custom class members that are defined as public.)

For example, the width_attr method implements support for a width identification property:

public String width_attr(Object obj) {
    return Integer.toString(((Component) obj).getBounds().width);
}

When your support class extends the support class of a functionally similar control, you do not have to implement support for those identification properties that apply without change to the custom control. For example, many controls have a label property. If the implemented support of the label property adequately supports the custom control, you do not need to override the parent's method.

You might inherit (or create) support methods for identification properties that are not included in the test object class definition. These identification properties are not displayed in UFT One in the Object Spy or in the Checkpoint Properties dialog box. You can access these identification properties by using the GetROProperty method. For more information on the GetROProperty method, see the UFT One Object Model Reference for GUI Testing.

To support identification properties of the custom control that are not supported by the parent support class, add new methods in your support class. To support identification properties that have the same name as supported ones, but a different implementation, override the parent methods.

UFT One uses a number of identification properties internally and expects them to have a specific implementation:

  • UFT One supports the following identification properties for every test object class and uses these properties to retrieve specific information about the object. Do not override UFT One's implementation of these identification properties in your toolkit support set: index (or class_index), class (or class_name), to_class, toolkit_class.

  • In JavaTree and JavaList test objects, there are identification properties named tree_content and list_content (respectively) that are used in checkpoints. UFT One calculates these properties based on the count identification property and the GetItem test object method, as follows: UFT One retrieves the count identification property, and calls the GetItem test object method for each item in the tree or list (from zero to count-1).

    If you override the implementation of count_attr or GetItem_replayMethod, you must make sure that they return the type of information that UFT One expects. For example, count_attr must return a numeric value and GetItem_replayMethod must return an item for each index from zero to count-1.

    If you map a custom control to the JavaTree or JavaList test object classes, and the custom support class does not inherit the count_attr and GetItem_replayMethod methods, you must implement them to return the information that UFT One expects.

The following basic identification property support methods are commonly used when creating support classes. In Tutorial: Learning to Create Java Custom Toolkit Support, you can practice using some of these methods:

  • The to_class_attr method (described in Mapping a Custom Control to a Test Object Class) supports the Class Name identification property. It provides the mapping of the custom control to a test object class, by returning the name of the relevant test object class. UFT One uses this property to determine which test object class is mapped to the custom control.

  • The name of a test object is determined by its tag property. All AWT support classes extend ObjectCS. ObjectCS implements the tag_attr method to check a set of properties in a specified order and to return the first valid value it finds. A valid value is one that is not empty and does not contain spaces.

    In the ObjectCS class, the tag_attr method checks the following properties (in the order in which they are listed):

    • label

    • attached_text (for more details, see below)

    • unqualified custom class (the name of the class without the package name)

    To change the name of a custom control test object, do not override the tag_attr method in the support class. Instead, make use of its existing implementation and override the method label_attr.

  • ObjectCS, which all AWT support classes extend, also implements the attached_text_attr method. It searches for adjacent static-text objects close to the custom control and returns their text. This mechanism is useful for controls such as edit boxes and list boxes, which do not have their own descriptive text, but are accompanied by a label.

    You can create support for a custom static-text control to enable UFT One to use its label property as the attached text for an adjacent control. For more information, see New UFT One Custom Static-Text Support Class Wizard.

  • The class_attr method returns the name of the test object's generic type (for example: object, button, edit, menu, static_text). This is not the specific test object class mapped to the object, but the general type of test object class. If you are creating a support class for a static-text control, you must implement the class_attr method to return the string static_text. Otherwise, do not override it.

  • The value_attr method is not mandatory, but it implements the value identification property, which is commonly used to represent the current state of the control. For example, the value_attr method may return the name of the currently selected tab in a tab control, the path of the currently selected item in a tree, or the currently displayed item in a menu. If you are creating a new test object class, and the term current state is relevant, implement support for a value identification property. If your support class inherits a value_attr method, verify that its implementation is correct for the supported control.

See also: