Supporting Test Object Methods

The test object methods 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 test object methods is provided in the support class by implementing a replay method with the following signature for each test object method:

public Retval <test object method name>_replayMethod(Object obj, <... list of String arguments>)

The obj argument is the object that represents the custom control.

Replay methods accept only strings as arguments, and UFT One passes all arguments to them in a string format. To use the boolean or numeric value of the argument, use MicAPI.string2int.

Within the replay method, you carry out the required operation on the custom control by using the custom class public methods or by dispatching low-level events using MicAPI methods. (Note that the support class can access only those custom class methods that are defined as public.) For more information, see the API Reference.

For example, Click_replayMethod (in the ImageButtonCS class), supports the Click test object method on an ImageButton custom control:

public Retval Click_replayMethod(Object obj) {
    ImageButton button = (ImageButton) obj;
    MicAPI.mouseClick((Object) button, button.getWidth() / 2, button.getHeight() / 2);
    Return Retval.OK;
}

All replay methods must return a MicAPI.Retval value. The Retval value always includes a return code, and can also include a string return value. The return code provides information to UFT One about the success or failure of the test object method. The return value can be retrieved and used in later steps of a UFT One GUI test.

For example, the GetItem_replayMethod in the SearchBoxCS class (that supports the SearchBox custom control) returns the name of a specified item in addition to the return code OK: 

public Retval GetItem_replayMethod(Object obj, String Index) {
    SearchBox sb = (SearchBox) obj;
    int indexint;
    String item;
    indexint = MicAPI.string2int(Index);
    if (indexint == MicAPI.BAD_STRING) {
        return Retval.ILLEGAL_PARAMETER;
    }
    if (indexint < 0 || indexint > sb.getItemCount() - 1) {
        return Retval.OUT_OF_RANGE;}
    item = sb.getItem(indexint);
    return new Retval(RError.E_OK, item);
}

For more information on the MicAPI.Retval values recognized by UFT One, see the API Reference.

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

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

Do not override the implementation of fundamental UFT One methods, such as: CheckProperty, FireEvent, GetRoProperty, GetTOProperty, SetTOProperty, and WaitProperty.

Note: When supporting JavaTree and JavaList test objects, you must make sure that the count_attr and GetItem_replayMethod methods return the type of information that UFT One expects. For more information, see Reserved Identification Properties.

See also: