Additional Considerations

This section provides additional information to keep in mind when you design an OpenText Functional Testing Extensibility Testing Agent.

XML Case Sensitivity

XML syntax is case sensitive.

Validating XML Data

Validate the XML data that you provide to OpenText Functional Testing against the relevant schema file in the <Testing_Extensibility_installdir>\SDK\schemas folder.

Note: If you use a Bitmap element instead of a Rectangle element in your Active Screen XML, this part of your XML will not pass validation with the ActiveScreen Schema. The Bitmap element is supported by OpenText Functional Testing, but is not included in the schema file.

Supporting the micclass Identification Property

For internal use, OpenText Functional Testing adds a micclass identification property to every test object. The Testing Agent does not have to provide a value for this property. This property is not displayed in any of the OpenText Functional Testing dialog boxes. However, an OpenText Functional Testing user can retrieve the property using the GetTOProperty and GetTOProperties methods.

Returning a Test Object from a Test Object Method

A test object method may have to return a test object. For example, if a table contains test objects such as check boxes, the test object method that returns the cell content should return a test object.

The b coclass defined in the UFT Extensibility Virtual Object type library enables a method to return an object. To use the coclass, import TEAVirtualObject.idl into your project. The file is located in <Testing_Extensibility_SDK_installdir>\SDK\Ifs.

To return a test object from a test object method, create a TEAVirtualObjectImp object, set it with the run-time ID of the test object that you want to return, and return the virtual object from the test object method.

When OpenText Functional Testing runs a test object method that returns a virtual object, OpenText Functional Testing translates the virtual object to a real test object. This mechanism is transparent for the OpenText Functional Testing user, who can assign the returned test object to a variable and use it in subsequent test steps.

For example, in the support created for the Hours Report sample application, there is a test object that represents the entire application. This object contains a test object that represents the Working Hours Report list. Each of these test objects can be learned separately, but for the sake of demonstration, the DemoApp test object that represents the application also has a test object method (GetReport) that returns the test object for the Working Hours Report list.

The following code excerpt from the code designed to support the GetReport test object method illustrates how to return a test object using a virtual object:

                HRESULT CAppDlg::Run(/*in*/  BSTR        sMethod, 
                     /*in*/  SAFEARRAY*  arguments,
                     /*out*/ VARIANT*    vtRetValue,
                     /*out*/ CComBSTR&   sErrorMsg)
{
...
// Create Virtual test object and return it in the out parameter
CComPtr<ITEAVirtualObject> spVirtualObject;
spVirtualObject.CoCreateInstance(L"TEAVirtualObject.TEAVirtualObjectImp");
    if (spVirtualObject)
    {
// Get run-time ID for the Report test object
        CComVariant vtReoprtRtId = m_pWorkingHourReport->GetRuntimeID();

// Set run-time Id into the virtual test object
        spVirtualObject->SetRuntimeID(vtReoprtRtId);

// Return virtual test object in output parameter
        CComVariant vtVirtualObject(spVirtualObject);
        vtVirtualObject.Detach(vtRetValue);
    }
...

This example was taken from <Testing_Extensibility_SDK_installdir>\samples\HoursReport\<VisualStudio version>\src\TeaAutDemo\GUIElement.cpp within the CAppDlg::Run function.

When editing a test, an OpenText Functional Testing user could write the following steps to retrieve the test object for the Working Hours Report list and print the number of lines in the report in a message box:

Set var_Report = DemoApp("TEA Demo").GetReport()
MsgBox var_Report.GetReportLength()

Additional Information About the Testing Environment XML

When you define your test object model in the testing environment XML, there are many helpful attributes you can set. For more information, see Developing Support for the Test Object Model. For a full description of all possible elements and attributes, see the TestingEnvironment Schema.

Using the Withable Attribute

OpenText Functional Testing users can use the VBScript With keyword in tests, grouping consecutive statements with the same parent hierarchy. Using a With statement instructs OpenText Functional Testing to use the same run-time ID for all of the steps in the With block, and not to retrieve the run-time ID for each step according to the test object description.

For test objects whose run-time ID should be retrieved for each step, set the Withable attribute of the test object class in the testing environment XML to false.

Supporting Enumerations

OpenText Functional Testing can require a user to use values from a predefined list when entering a test object method argument. In the testing environment XML, you can define such predefined lists of values. You then use the name of the list of values in the argument type when you define the relevant test object method argument in the testing environment XML.

For example, you can define the enumeration type CtrlShift:

<ListOfValues Name="CtrlShift">
            <EnumValue Name="None" RealValue="0"/>
            <EnumValue Name="Ctrl" RealValue="1"/>
            <EnumValue Name="Shift" RealValue="2"/>
            <EnumValue Name="CtrlShift" RealValue="3"/>
</ListOfValues>

When defining a test object method argument that should use these values, define the argument's type as follows:

Mapping a Test Object Class to an OpenText Functional Testing Generic Type

When you set the GenericTypeID attribute of a test object class that you define in your testing environment XML to an existing generic type, you instruct OpenText Functional Testing to treat your test object as an object of that type. This means that:

OpenText Functional Testing provides a generic definition for the Documentation column in the Keyword View for test object methods that you support and are common to this generic type. For example, if you define that your test object class belongs to the generic type Button and you support a Click method, the Documentation string for your button object will be similar to the string used for all other buttons.
In situations where OpenText Functional Testing allows the user to filter test objects by type, objects of your test object class are considered objects of the generic type you defined. For example:
- In the Step Generator's Select Object for Step dialog box, the user can select to view only objects of a certain generic type.
- In the Select Object Type dialog box that can be reached when adding a container object to the object repository, the user can instruct OpenText Functional Testing to learn only the descendants of certain generic types.
- In the Find & Replace dialog box used to search for objects in the object repository, the user can refine the search according to the generic object type.

Mapping your test object class to a generic OpenText Functional Testing type does not provide support for test objects of this class. The Testing Agent must implement support for all of the test object methods and identification properties of this test object class. The Testing Agent must perform the relevant operations when the test object methods are called and return the identification property values when required.

Supporting Statement Completion

To support statement completion within OpenText Functional Testing, install the testing environment XML in folder <OpenText Functional Testing installdir>\dat\Extensibility\tea. The file name must have an XML extension.