Deploying and Running the Custom Toolkit Support

The final stage of extending UFT One 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 UFT One.

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

About Deploying the Custom Toolkit Support

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

When UFT One 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 instruct UFT One 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:

  • UFT One recognizes the controls in your custom toolkit and can run test steps on them.

  • UFT One displays the name of your custom toolkit in the Environment list in all of the dialog boxes that display lists of add-ins or supported environments.

  • UFT One displays the list of test object classes defined by your toolkit support set in 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.)

    Note: Test object classes defined in a toolkit support set that was developed using a Java Add-in Extensibility SDK version earlier than 10.00 are displayed in the UFT One dialog boxes as Java test object classes. To cause UFT One to display these test object classes under the correct environment name, change the PackageName attribute in the test object configuration file to the name of the custom toolkit, as it appears in the Add-in Manager. Additionally, if an index identification property is implemented for any test object classes in the toolkit support set, remove this implementation to enable the use of the Generate Scripts button in the Object Identification dialog box.

Back to top

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

<UFT One Installation Folder>\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.

  • <UFT One Installation Folder>\Dat\Extensibility\Java

  • <UFT One Add-in for ALM Installation Folder>\Dat\Extensibility\Java
    (Optional. Required only if the folder exists, which means the UFT One Add-in for ALM was installed independently from the ALM Add-ins page and not as part of the UFT One installation.)

<Custom Toolkit Name>Support.class

All of the compiled Java support classes can be packaged in class folders or Java archives on the computer on which UFT One is installed, or in an accessible network location.

Specify the location in <Custom Toolkit Name>.xml.

<CustomClass>CS.class

Icon files for new test object classes (optional)

The file can be a .dll or .ico file, located on the computer on which UFT One is installed, or in an accessible network location.

Specify the location in <Custom Toolkit Name>TestObjects.xml.

Back to top

Modifying Deployed Support

If you modify a toolkit support set that was previously deployed to UFT One, 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 UFT One 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 UFT One, see Modifying Identification Property Attributes in a Test Object Configuration File.

Back to top

Removing Deployed Support

When opening UFT One, the UFT One user can use the Add-in Manager to instruct UFT One 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 in UFT One.

  • If you want to remove support for a custom toolkit from UFT One after it is deployed, you must delete its toolkit configuration file from: <UFT One Installation Folder> 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: <UFT One Installation Folder>\Dat\Extensibility\Java (and <UFT One Add-in for ALM Installation Folder>\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 UFT One 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.

Back to top

See also: