Implementing support for test object methods
After enabling OpenText Functional Testing to recognize the custom controls, you must provide support for running test object methods. If you try to run a test with steps that run on custom test objects before providing implementation for these methods, the test fails and a run-time error occurs.
For each test object method that you defined in the test object configuration file, you must write a JavaScript function that is used to perform the step on the control. In addition to performing the step, you can design the JavaScript function to add a line to the run results, add log messages to the event log, and display messages boxes to the user, as necessary. For more information, see Designing JavaScript functions for your toolkit support set.
In the toolkit configuration file, you need to specify the JavaScript file in which to find the JavaScript functions and, optionally, the name of the function to use for each test object method.
You can specify a JavaScript file and function for each test object method in the toolkit configuration file, or you can define a default JavaScript file per toolkit (Controls element) or per test object class (Control element). The default files are used for all test objects methods for which you do not specify an implementation file. By default, the JavaScript functions are expected to have the same name as the test object method. Therefore, you do not need to specify function names in the toolkit configuration file, unless you choose to name a function something other than the corresponding test object method name. For more information, see the Toolkit Configuration Schema Help.
Caution: Do not create JavaScript functions named get_property_value or get_list_of_values. These names are reserved for the JavaScript functions that are called (by default) to retrieve run-time values of test object identification properties and lists of possible values for test object method arguments.
For more information, see Supporting dynamic lists of values for method arguments.
After you create support for running test object methods, you can run GUI tests on your custom test objects, and verify that your toolkit support set performs correctly. For more information on testing your toolkit support set, see Testing the toolkit support set during development.
The following example is taken from the ASPAjax toolkit support set, which includes support for a Select method on the ASPAjaxTabs test object. In the ASPAjax test object configuration file, this is declared as follows:
<ClassInfo BaseClassInfoName="WebElement" Name="ASPAjaxTabs"
DefaultOperationName="Select" >
<TypeInfo>
<Operation ExposureLevel="CommonUsed" Name="Select" PropertyType="Method">
<Description>Selects the specified tab.</Description>
<Documentation>
<![CDATA[Select the tab with index %a1.]]>
</Documentation>
<Argument Name="Index" IsMandatory="true" Direction="In">
<Type VariantType="Integer"/>
<Description>
The index value of the tab to select.
</Description>
</Argument>
</Operation>
</TypeInfo>
</ClassInfo>
In the toolkit configuration file, the Control\Settings element for the ASPAjaxTabs test object class is defined as follows:
<Control TestObjectClass="ASPAjaxTabs">
<Settings>
<!-- Indicates the location of the JavaScript file that contains the implementation of the script -->
<variable name="default_imp_file" value="Tabs.js"/>
</Settings>
</Control>
No Run element is defined for this test object class. Therefore, when a step with the Select test object method runs, the Tabs.js file is searched (as defined in the toolkit configuration file) for a JavaScript function named Select.
In the Tabs.js file, the Select JavaScript function is implemented to accept an index and select the tab with that index.

