Describing the Test Object Model

The first stage of developing support for custom controls is to introduce the test object model that you want UFT One to use to test your applications and controls. The test object model is a list of the test object classes that represent custom controls in your environment and the syntax of the test object methods that support the custom controls.

You define the test object model in a test object configuration file according to a specific XML schema.

Benefits of Describing Test Object Models

Implementation of a test object configuration file is optional. If you choose not to implement the test object configuration file, the test object methods defined in the .NET Custom Server DLL or control definition files will work as expected, but the functionality listed below will be missing.

Describing your custom test object methods in a test object configuration file enables the following functionality when editing GUI tests in UFT One:

A list of available custom test object methods in the Operations column in the Keyword view and when using the statement completion feature in the Editor.
A test object method selected by default in the Keyword View and Step Generator when a step is generated for a test object of this class.
Documentation for the custom test object methods in the Documentation column in the Keyword view.
Icons and context-sensitive Help (only for new test object methods added to a test object class).

Creating Test Object Configuration Files

The following steps describe how to create test object configuration files.

Create a copy of the <UFT One installation folder>\dat\Extensibility\DotNet\DotNetCustomServerMethods.xml file to create a new test object configuration file in the same folder. (Do not modify the original file.)
Edit the new test object configuration file, modifying any test object classes whose behavior you want to modify. Delete any test object classes that you do not modify.
Save and close the test object configuration file.

Understanding the Contents of the Test Object Configuration File

A test object configuration file can include the following:

The name of the test object class and its attributes.
The name of the custom control for which this test object class definition is relevant.
The methods for the test object class, including the following information for each method:
- The arguments, including the argument type and direction.
- Whether the argument is mandatory, and, if not, its default value.
- The description (shown as a tooltip in the Keyword View, Editor, and Step Generator).
- The documentation string (shown in the Documentation column of the Keyword View and in the Step Generator).
- A context-sensitive Help topic to open when F1 is pressed for the test object method in the Keyword View or Editor, or when the Operation Help button is clicked for the method in the Step Generator. The definition includes the Help file path and the relevant Help ID within the file. (Relevant only for new test object methods added to the test object class.)
- The return value type.
The test object method that is selected by default in the Keyword View and Step Generator when a step is generated for a test object of this class.

The following example shows parts of the SwfObject test object class definition in a test object configuration file. The example shows that the SwfObject is extended by adding a MyCustomButtonSet method. The method has one argument (Percent, which defines the percentage to set in the control), and it also has a documentation string that appears in the Keyword View:

</TypeInformation>
...
    <ClassInfo BaseClassInfoName="SwfObject" Name="MyCompany.MyButton">
...
        <TypeInfo>
            <Operation Name="MyCustomButtonSet"PropertyType="Method" ExposureLevel="CommonUsed">
                  <Description>Set the percentage in the task bar</Description>
                  <Documentation><![CDATA[Set the %l %t to <Percent> percent.]]></Documentation>
                    <Argument Name="Percent" IsMandatory="true" Direction="In">
                        <Type VariantType="Integer"/>
                        <Description>The percentage to set in the task bar.</Description>
                    </Argument>
            </Operation>
        </TypeInfo>
    </ClassInfo>
</TypeInformation>

For information on the structure and syntax of a test object configuration file, see the UFT One Test Object Schema Help

Modifying an Existing Test Object Class

Identify a test object class that provides partial support for your control, but needs some modification, for example, additional or modified test object methods.

You can then extend the functionality of this test object by defining and implementing additional test object methods. In addition, you can override existing test object methods by providing an alternate implementation for them. You define the new or changed methods in the test object configuration file, and design their implementation using Custom Servers.

Adding Test Object Methods to an Existing Test Object Class

When you create a test object class definition in the test object configuration file, you specify the custom control for which this definition is relevant. (In the ClassInfo element, you specify the test object class in the BaseClassInfoName attribute, and the name of the custom class in the Name attribute.)

If you then add a custom test object method to the definition of this test object class, this method is available in UFT One only for test objects that represent custom controls of the type you specified.

For example, if you added a Set method to the SwfEditor test object class when used for MyCompany.MyButton controls, then the method is displayed in the statement completion list of test object methods in UFT One only for objects that represent such controls. When SwfEditor test objects are used for other types of controls, this method is not available.

Make Sure that Test Object Configuration File Information Matches Custom Server Information

Make sure that the information you define in the test object configuration file exactly matches the corresponding information defined in the .NET Custom Server DLL or control definition files. For example, the test object method names must be exactly the same in both locations. Otherwise, the methods appear to be available (for example, when using the statement completion feature) but they do not work, and, if used, the run session fails. In addition, the custom control name specified in the test object configuration file must be the same as the name specified in the .NET Add-in Extensibility configuration file.

Implementing More Than One Test Object Configuration File

You can choose to implement one or multiple test object configuration files (or none, if not needed). For example, you can define custom methods for one test object class in one test object configuration file, and custom methods for another test object in a different test object configuration file. You can also choose to define a group of custom methods for a test object class in one test object configuration file, and another group of custom methods for the same test object class in a different test object configuration file.

Each time you open UFT One, it reads all of the test object configuration files and merges the information for each test object class from the different files into a single test object class definition. This enables you to use the same test object class definitions when supporting different custom toolkits.

Example of a Test Object Configuration File

The following example shows the definition of the ToolStrip test object:

<ClassInfo Name="System.Windows.Forms.ToolStrip" aseClassInfoName="SwfToolBar" FilterLevel="1">
    <TypeInfo>
        <Operation Name="Select" PropertyType="Method ExposureLevel="CommonUsed" SortLevel="-1">
            <Description>Selects a menu item from a SwfToolBar dropdown menu.
            </Description>
            <Argument Name="Item" Direction="In" IsMandatory="true">
                <Type VariantType="VT_BSTR"/>
            </Argument>
        </Operation>
        <Operation Name="IsItemEnabled" PropertyType="Method" ExposureLevel="Expert" SortLevel="-1">
            <Description>Indicates whether the toolbar item is enabled.</Description>
            <Argument Name="Item" Direction="In" IsMandatory="true">
                <Type VariantType="VT_BSTR"/>
            </Argument>
            <ReturnValueType><Type VariantType="VT_BOOL"/></ReturnValueType>
        </Operation>
        <Operation Name="ItemExists" PropertyType="Method" ExposureLevel="Expert" SortLevel="-1">
            <Description>Indicates whether the specified toolbar item exists.</Description>
            <Argument Name="Item" Direction="In" IsMandatory="true"> 
                <Type VariantType="VT_BSTR"/>
            </Argument>
            <ReturnValueType> <Type VariantType="VT_BOOL"/></ReturnValueType>
        </Operation>
    </TypeInfo>
</ClassInfo>

This example shows that the ToolStrip test object class extends the SwfToolBar test object class. The default test object method for the ToolStrip test object class is Select (which has one mandatory input parameter: Item).