Web Add-in Extensibility Developer Guide > Working with Web Add-in Extensibility > Planning UFT Support for Your Toolkit > Determining the Support Information for Each Custom Control Type > Understanding the Web Add-in Extensibility Planning Checklist

Understanding the Web Add-in Extensibility Planning Checklist

When you plan the support for a specific type of control, you must ask yourself a series of questions. These are explained below and are available in an abbreviated, printable checklist.

  1. Make sure you have access to an application that runs the custom control on a computer with UFT installed.

  2. Is there an existing Web test object class which can be extended to represent the custom control? If so, which one? If not, your new test object class needs to extend the WebElement class.

  3. If the new test object class extends a base test object class other than WebElement, does the control contain an element of the type normally represented by the base test object class (also referred to as a base element)?

    • If not, you will need to implement test object methods inherited from the base class that not supported by WebElement. In addition, you will need to design a method that returns values for all of the test class' identification properties that are not supported by WebElement.

    • If the control includes a base element, is it the root Web element of the control?

      • If it is the root element, UFT will use its internal implementation for the inherited test object methods and identification properties that you do not override.

      • If the base element is not the root element, you need to implement a JavaScript function that returns the base element.

  4. Define the details for the new test object class that will represent the custom control in UFT GUI tests.

    When you design the toolkit support set, you specify this information in the test object configuration file. For more information, see Understanding the Test Object Configuration File.

    1. Specify the test object class name.

    2. Do you want the new test object class to belong to a different generic type than the one to which the base class belongs? If so, specify the generic type. (For example, if your new test object class extends WebElement (whose generic type is object), but you would like UFT to group this test object class with the edit test object classes.)

    3. Do you want UFT to use a different icon for the new test object?

      If so, make sure the icon file is available in an uncompressed .ico format. Recommended location: <UFT installation folder>\dat\Extensibility\<UFT add-in name>\Toolkits\<Environment name>\Res.

    4. Specify one or more identification properties that can be used to uniquely identify the control (in addition to the test object class).

    5. Specify the default test object method to be displayed in the Keyword View and Step Generator when a step is generated for a test object of this class.

    6. Do you want to provide a Help file, which UFT will open when F1 is pressed for test objects of this class in the Keyword View or Editor?

      If so, make sure that the Help file is available in .chm format. Recommended location: <UFT installation folder>\dat\Extensibility\<UFT add-in name>\Toolkits\<Environment name>\Help.

  5. Decide how to design the process of identifying the test object class to use for this control.

    • Do you want to limit the process to HTML elements with specific HTML tags? If so, which? Make sure to include all HTML tags that can be relevant for your custom control.

    • Which HTML properties will you use to determine what test object class represents controls of this type?

    • Do you need to create different identification rules to use when the control runs on different browsers?

    For more information, see Teaching UFT to Identify the Test Object Class to Use for a Custom Web Control.

  6. Specify the basis for naming the test object that represents the control.

  7. What identification properties do you want to support? Which properties should be displayed in the Checkpoint Properties and Output Value Properties dialog boxes in UFT, and which should be selected by default in this dialog box? Which identification properties can be used for Smart Identification?

  8. What test object methods do you want to support? Specify the method argument types and names, and whether the method returns a value in addition to the return code.

    Optionally, specify the location of a Help file, which UFT will open when F1 is pressed in the Keyword View or Editor or the Operation Help button is clicked in the Step Generator for a test object method.

  9. Do you want to dynamically provide a list of possible values for any test object method arguments? Which?

  10. Which types of children should UFT learn with the control?

  11. Should the Object Spy display test objects of this class?

  12. Do you want to provide support for creating UFT GUI tests by recording?

    If so, list the events you want to record on the custom control during a UFT recording session.

  13. Determine what parts of the support need to be designed in the toolkit configuration file and what parts need JavaScript functions.