Deploying and Running the Custom Toolkit Support

The final stage of extending support for a custom toolkit is deployment. This means placing all of the files you created in the correct locations, so that the custom toolkit support is available to OpenText Functional Testing.

You can also deploy the toolkit support during the development stages, to test how it affects OpenText Functional Testing and debug the custom toolkit support set that you are creating.

About Deploying the Custom Toolkit Support

From the OpenText Functional Testing user's perspective, after you deploy the toolkit support set on a computer on which OpenText Functional Testing is installed, the toolkit support set can be used as an OpenText Functional Testing add-in.

When OpenText Functional Testing opens, it displays the custom toolkit name in the Add-in Manager, as a child node under the Java Add-in node. Select the check box for your custom toolkit to load support for the toolkit using the toolkit support set that you developed.

Note: Only applications that are opened after loading or unloading support for the custom toolkit are affected.

If you do not load the support for your custom toolkit, the code that you designed in your toolkit support set does not run.

If you load support for your custom toolkit:

Controls in your custom toolkit are recognizes and test steps can run on them.
The name of your custom toolkit is displayed in the Environment list in all of the dialog boxes that display lists of add-ins or supported environments.
The list of test object classes defined by your toolkit support set is displayed in the dialog boxes that display the list of test object classes available for each add-in or environment. (For example: Define New Test Object dialog box, Object Identification dialog box.)

Deploying the Custom Toolkit Support

The following table describes the appropriate location for each of the toolkit support files:

File Name	Location
<Custom Toolkit Name>.xml	<OpenText Functional Testing installdir>\bin\java\classes\extension
<Custom Toolkit Name>TestObjects.xml Optional. Required only if mapping custom classes to new test object classes. Note: This file name convention is used by the Java Add-in Extensibility wizard. You can have more than one test object configuration file, and name them as you wish.	<OpenText Functional Testing installdir>\Dat\Extensibility\Java <OpenText Functional Testing_Add-in_for ALM_installdir>\Dat\Extensibility\Java (Optional. Required only if the folder exists, which means the OpenText Functional Testing Add-in for ALM was installed independently from the Add-ins page and not as part of the OpenText Functional Testing installation.)
<Custom Toolkit Name>Support.class <CustomClass>CS.class	All of the compiled Java support classes can be packaged in class folders or Java archives on the computer on which OpenText Functional Testing is installed, or in an accessible network location. Specify the location in <Custom Toolkit Name>.xml.
Icon files for new test object classes (optional)	The file can be a .dll or .ico file, located on the computer on which OpenText Functional Testing is installed, or in an accessible network location. Specify the location in <Custom Toolkit Name>TestObjects.xml.

Deploying Custom Support During the Development Stage

During the design stages of the custom toolkit support, the support class files can remain in your workspace. You deploy the custom toolkit support by placing the toolkit configuration files (including the test object configuration file) in the correct locations, and by specifying the location of the compiled support classes in the toolkit configuration (XML) file. In addition, if your new test object classes use specific icons, specify their locations in the test object configuration file.

Note: Compile the support classes before deploying and check for compilation errors, to avoid run-time failure.

If you modify attributes of Identification Property elements in the test object configuration file, it is recommended to keep the DevelopmentMode attribute of the TypeInformation element set to true during the design stages of the custom toolkit support. For more information, see Modifying Identification Property Attributes in a Test Object Configuration File.

If you develop custom toolkit support using the Java Add-in Extensibility plug-in in Eclipse, and OpenText Functional Testing is installed on your computer, you deploy toolkit support by clicking the Deploy Toolkit Support Eclipse toolbar button, or by choosing UFT > Deploy Toolkit Support. The XML configuration files are copied to the correct OpenText Functional Testing locations, while the Java class files remain in the Eclipse workspace. (The actual locations of the toolkit support class and the custom support classes are listed in the toolkit configuration file.) For details on deploying support using the Eclipse plug-in, see Deploy Toolkit Support .

If you do not use the Java Add-in Extensibility plug-in in Eclipse, or if OpenText Functional Testing is installed on another computer, you must perform the deployment manually, according to the information in the table.

To deploy custom support manually during the development stages:

Make sure that the compiled support classes (toolkit support class and custom support classes) are in a location that can be accessed by OpenText Functional Testing.
Update the configuration files with the correct locations of the compiled support classes and icon files (if relevant).
Copy the configuration files to the appropriate folders, as described in the table.

Deploying Custom Support After the Design is Completed

When the custom toolkit support is fully designed, you can deploy it to any computer on which OpenText Functional Testing is installed.

If you set the DevelopmentMode attribute of the TypeInformation element in the test object configuration file to true while developing the custom toolkit support, make sure to remove this attribute (or set it to false) before deploying the custom support for regular use. For more information, see Modifying Identification Property Attributes in a Test Object Configuration File.

To deploy custom support after the design is completed:

Place the compiled support classes (toolkit support class and custom support classes) in their permanent location. The classes can be in class folders or in a Java archive, in a location that can be accessed by OpenText Functional Testing.
In addition, if you have new test object classes using specific icons, place the icon files in a location that can be accessed by OpenText Functional Testing.
Update the toolkit configuration file with the correct location of the compiled support classes.
If necessary, update the test object configuration file with the correct location of the icon files.
Copy the configuration files to the appropriate folders, as described in the table.

Testing the deployed support

After you deploy the custom toolkit support, you can perform OpenText Functional Testing operations on an application that contains the supported custom controls to test the effects of the support.

You can run the application in any way you choose.

If you run an SWT application from Eclipse using a version earlier than 3.3, Eclipse overrides the Java library path to add the SWT dll. Therefore, you must add the jvmhook.dll path (required by the Java Add-in) to the library path manually.

To add the jvmhook.dll path to the library path (when working with Eclipse versions earlier than 3.3):

Right-click the application file in the Eclipse Package Explorer. Select Run As > SWT Application.
In the Eclipse toolbar, select Run > Run. The Run dialog box opens.
Select the SWT application in the Configurations list.
Click the Arguments tab.
In the VM arguments area, enter:
```
-Djava.library.path=<System Folder>\system32
```
(For example: -Djava.library.path=c:\WINNT\system32)
Close the application and run the application again. (Right-click the application file in the Eclipse Package Explorer and select Run As > SWT Application).

Modifying Deployed Support

If you modify a toolkit support set that was previously deployed to OpenText Functional Testing, the actions you must perform depend on the type of change you make, as follows:

If you modify the toolkit configuration file or a test object configuration file, you must deploy the support.
If you modify a test object configuration file, you must reopen OpenText Functional Testing after deploying the support.
Whether you modify the configuration files or only the Java support classes, you must re-run the Java application for the changes to take effect.

If you change the identification property definitions that specify the functionalities for which the properties are used in OpenText Functional Testing, see Modifying Identification Property Attributes in a Test Object Configuration File.

Removing Deployed Support

When opening OpenText Functional Testing, the user can use the Add-in Manager to indicate whether to load the support provided for any particular toolkit. If the support for your custom toolkit is not loaded, the code that you designed in your toolkit support set does not run, and the test object classes that you defined in the test object configuration file are not available.

If you want to remove support for a custom toolkit from OpenText Functional Testing after it is deployed, you must delete its toolkit configuration file from: <OpenText Functional Testing installdir>\bin\java\classes\extension
If none of the test object class definitions in a test object configuration file are mapped to any custom controls (meaning they are no longer needed), you can delete the file from: <OpenText Functional Testing installdir>\Dat\Extensibility\Java (and <OpenText_Functional_Testing_Add-in_for_ALM_installdir>\Dat\Extensibility\Java if relevant).
If you want to remove only parts of the custom toolkit support that you created, consider the following:
- To remove support for a specific custom class, delete its custom support class, and remove the references to this support class from the toolkit configuration file.
  Before you delete a custom support class, make sure that no other custom support classes extend it.
- To remove a new test object class that you defined, remove its definition from the test object configuration file.
  Before you remove the definition of a test object class, make sure that no custom classes are mapped to this test object class and that no other test object classes extend it.
- To remove support for test object methods or identification properties that you added, remove the relevant support methods from your custom support class.
  Removing support for test object methods or identification properties from the support class does not remove them from the test object class definition. They are available in when editing tests but are not supported for this custom class.
- To remove your custom support for test object methods or identification properties whose implementation you overrode, remove the relevant support methods from your custom support class.
- To remove test object methods or identification properties from the test object class definition, remove them from the test object configuration file.