Toolkit Configuration Schema Overview

In a toolkit configuration XML, you must define a Control element for each test object class that you plan to use to support controls in your toolkit. Each Control element must include a TestObjectClass attribute that specifies the name of the test object class to which it applies.

The Control elements are contained within one Controls element, which represents the toolkit as a whole.

The toolkit configuration file must provide information that enables UFT to identify which test object class to use for each control in the toolkit. This information can be provided at toolkit level or at control level, as described in the following sections.

The toolkit configuration XML can also contain additional information. A brief summary of the possible content of this XML is provided below and more detail on how to design and use the toolkit configuration XML is provided in the subsequent sections of this guide.

The toolkit specific information can include:

  • The priority of the toolkit. When UFT attempts to identify the test object class mapped to a custom control, it searches in the different toolkits in the order of their priority (highest priority first).
  • An identification function (and optionally the name of the file that contains the function) used to identify the test object class to use for each control in the toolkit.
  • The name of the default file from which implementation functions are called if no file is specifically defined for a test object class.
  • JavaScript libraries for UFT to inject into the Web page, enabling you to call the library functions from the support functions that you design.

A test object class element can include:

  • HTML tags and identification conditions or an identification function (and optionally the name of the file that contains the function) used to identify the custom controls that should be represented by this test object class.
  • The name of the default file from which implementation functions are called if no file is specifically defined for a function.
  • A function (and optionally the name of the file that contains that function) that returns the element whose test object implements the properties and test object methods inherited from the base class and not implemented for this control.
  • The functions (and optionally the name of the file containing those functions) that implement the test object methods of this test object class. UFT calls these functions to perform test steps on the control. If no functions are defined, UFT calls implementation functions with the same name as the test object methods.
  • The function (and optionally the name of the file containing the function) that retrieves the identification properties from the control. If no function is defined, UFT calls a function named get_property_value.
  • Elements that indicate whether to use the default Web Event Configuration for handling events on the control and its children, and can specify functions that UFT should run to perform customized event listening and handling.
  • Elements that indicate when to learn the control and its children, and optionally, a function that specifies which children to learn.
  • Elements that indicate whether to display test objects of this class in the Object Spy.
  • Elements that indicate whether the test object is a container for other test objects in the object repository.
  • A function (and optionally the name of the file containing the function) that retrieves the list of possible values for a test object method argument from the control. If no function is defined, UFT calls a function named get_list_of_values.
  • A function (and optionally the name of the file containing the function) that retrieves the state of the supported toolkit, checking whether it is fully loaded on the current Web page.

Note: When planning the order of the Control elements in this file, consider that UFT follows this order when searching for a test object class to match a control. The first matching test object class is used.