Additional Considerations When Working with UFT One Testing Extensibility

This section provides additional information to keep in mind when you design a UFT One Testing Extensibility Testing Agent.

XML Case Sensitivity

XML syntax is case sensitive.

Back to top

Validating XML Data

Validate the XML data that you provide to UFT One against the relevant schema file in the <UFT One Testing Extensibility installation folder>\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 UFT One, but is not included in the schema file.

Back to top

Supporting the micclass Identification Property

For internal use, UFT One 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 UFT One dialog boxes. However, a UFT One user can retrieve the property using the GetTOProperty and GetTOProperties methods.

Back to top

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 <UFT One Testing Extensibility SDK installation folder>\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 UFT One runs a test object method that returns a virtual object, UFT One translates the virtual object to a real test object. This mechanism is transparent for the UFT One 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 <UFT One Testing Extensibility SDK installation folder> \samples\HoursReport\<VisualStudio version>\src\TeaAutDemo\GUIElement.cpp within the CAppDlg::Run function.

When editing a test, a UFT One 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()

Back to top

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.

Back to top

Using the Withable Attribute

UFT One users can use the VBScript With keyword in tests, grouping consecutive statements with the same parent hierarchy. Using a With statement instructs UFT One 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.

Back to top

Supporting Enumerations

UFT One 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:

<Type VariantType="Enumeration" ListOfValuesName="CtrlShift"/>

Back to top

Mapping a Test Object Class to a UFT One 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 UFT One to treat your test object as an object of that type. This means that:

  1. UFT One 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.

  2. In situations where UFT One 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 UFT One 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.

  3. Mapping your test object class to a generic UFT One 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.

Back to top

Supporting Statement Completion

To support statement completion within UFT One, install the testing environment XML in folder <UFT installation folder>\dat\Extensibility\tea. The file name must have an XML extension.

Back to top