Designing Your Test Object Configuration XML File

In this file, you define any custom test object classes that you want OpenText Functional Testing to use to represent your custom controls in tests and components. Define a test object class for each custom control that cannot be adequately represented by an existing Delphi test object class.

Overview

In a test object configuration XML, you define the test object classes (for example, the test object methods they support and their identification properties).

You can also create a definition for an existing test object class in the test object configuration XML. This definition is added to the existing definition of this test object class, affecting all test objects of this class. It is therefore not recommended to modify existing test object classes in this way. For example:

  • If you add a test object method, it appears in the list of test object methods in OpenText Functional Testing, but if you use the test object method in a test, and it is not implemented for the specific object, a run-time error occurs.

    If you add test object methods to existing test object classes, you might add a prefix to the method name that indicates the toolkit support for which you added the method (for example, CustomButtonClick, CustomEditSet). This enables test designers to easily identify the custom methods and use them in test steps only if they know that the custom method is supported for the specific object.

  • If you add an identification property, it appears in OpenText Functional Testing in the list of properties for all test objects of this class, but has no value unless it is implemented for the specific supported object.

In the test object configuration XML file, you create a ClassInfo element for each test object class that you want to define. In addition, you define the name of the environment or custom toolkit for which the test object classes are intended (in the PackageName attribute of the TypeInformation element), and the OpenText Functional Testing add-in which these test object classes extend (in the AddinName attribute of the TypeInformation element).

If the relevant add-in is not loaded when OpenText Functional Testing opens, the information in this XML is not loaded. Similarly, if the name of the environment or custom toolkit is displayed in the Add-in Manager dialog box and its check box is not selected, the information in this XML is not loaded.

To ensure the structural correctness of your test object configuration file, you can validate it against the ClassesDefintions.xsd file. This file is installed with OpenText Functional Testing, in the <OpenText Functional Testing installdir>\dat folder. (For backward compatibility reasons, certain XML structures that do not pass validation against this XSD are still supported.)

For information on the structure and syntax of this XML, see the Test Object Schema Help.

Back to top

A Test Object Class Definition

The sections below describe the information that you can include in a test object class definition. Class name and type, methods and properties, an icon file, and a Help file.

Class Name and Base Class

The name of the new test object class and its attributes, including the base class—the test object class that the new test object class extends. A new test object class extends an existing DelphiOpenText Functional Testing test object class, directly or indirectly. The base class may be a class delivered with OpenText Functional Testing or a class defined using Delphi Add-in Extensibility.

By default, the base class is DelphiObject.

The test object class name must be unique among all of the environments whose support might be loaded simultaneously. For example, when defining a new test object class, do not use names of test object classes from existing OpenText Functional Testing add-ins, such as DelphiButton or DelphiEdit.

Note: A test object class inherits the base class' test object operations (methods and properties), generic type, default operation, and icon. Identification properties are not inherited.

Generic Type

The generic type for the new test object class, if you want the new test object class to belong to a different generic type than the one to which its base class belongs. (For example, if your new test object class extends DelphiObject (whose generic type is object), but you would like to group this test object class with the edit test object classes.)

Generic types are used when filtering objects (for example, in the Step Generator's Select Object for Step dialog box and when adding multiple test objects to the object repository). Generic types are also used when creating documentation strings for the Documentation column of the Keyword View (if they are not specifically defined in the test object configuration file).

Test Object Operations

A list of operations for the test object class, including the following information for each operation:

  • The arguments, including the argument type (for example, String or Integer), direction (In or Out), whether the argument is mandatory, and, if not, its default value.

  • The operation description (shown in the Object Spy and as a tooltip in the Keyword View and Step Generator).

  • The Documentation string (shown in the Documentation column of the Keyword View and in the Step Generator).

  • The return value type.

  • A context-sensitive Help topic to open when F1 is pressed for the test object operation in the Keyword View or Editor, or when the Operation Help button is clicked for the operation in the Step Generator. The definition includes the Help file path and the relevant Help ID within the file.

Default Operation

The test object operation that is selected by default in the Keyword View and Step Generator when a step is generated for an object of this class.

Identification Properties

A list of identification properties for the test object class. You can also define:

  • The identification properties that are used for the object description.

  • The identification properties that are used for smart identification. (This information is relevant only if smart identification is enabled for the test object class. To enable smart identification, use the Object Identification dialog box in OpenText Functional Testing.)

  • The identification properties that are available for use in checkpoints and output values.

  • The identification properties that are selected by default for checkpoints (in the OpenText Functional Testing Checkpoint Properties dialog box).

When defining identification properties, it is recommended to start by copying existing identification properties from the base object in your schema or from similar objects in related toolkits.

Icon File

The path of the icon file to use for this test object class. (Optional. If not defined, the base class' icon is used.) The file can be a .dll, .exe, or .ico file.

Help File

A context-sensitive Help topic to open when F1 is pressed for the test object in the Keyword View or Editor. The definition includes the .chm Help file path and the relevant Help ID within the file.

Back to top

Attributes That Are Configurable in OpenText Functional Testing

The following attributes of the Identification Property element in the test object configuration file specify information that can be modified in OpenText Functional Testing (using the Object Identification dialog box): AssistivePropertyValue, ForAssistive, ForBaseSmartID, ForDescription, ForOptionalSmartID, and OptionalSmartIDPropertyValue. These attributes determine the lists of identification properties used for different purposes in OpenText Functional Testing.

Therefore, by default, OpenText Functional Testing reads the values of these attributes from the XML only once, to prevent overwriting any changes a user makes using the Object Identification dialog box. In this way, OpenText Functional Testing provides persistence for the user defined property lists. For more information, see Modifying Identification Property Attributes in a Test Object Configuration File.

Back to top