Planning Your Support Set

Before you begin to create support for custom controls, you must carefully plan the support. Detailed planning of how you want UFT One to recognize the custom controls enables you to correctly build the fundamental elements of the .NET Add-in Extensibility support set.

About Planning UFT One GUI Testing Support for Your .NET Add-in Extensibility Controls

Extending the UFT One .NET Add-in's support to recognize custom .NET Windows Forms controls is a process that requires detailed planning. To assist you with this, the following sections include sets of questions related to the implementation of support for your custom controls. When you create your .NET Add-in Extensibility support set, you implement it based on the answers you provide to these questions.

Determining Information Related to Your Custom Controls

Decide which controls this support set will support.

Before you begin planning support for custom .NET Windows Forms controls, make sure you have full access to the controls and understand their behavior.

You must have an application in which you can view the controls in action.

You must also be able to view the source that implements them. You do not need to modify any of a custom control's sources to support it in UFT One, but you do need to be familiar with them.

When planning custom support for a specific type of control, carefully consider how you want UFT One to handle controls of this type. For example, what type of test object you want to represent the controls in UFT OneGUI tests and which test object methods you want to use. Make these decisions based on the business processes that might be tested using this type of control and operations that users are expected to perform on these controls:

Make sure you know, for example, the methods the control supports, what properties it has, and what events you can listen for.
Identify existing test object classes whose functionality is similar to that of the custom .NET Windows Forms controls.
Decide what methods need to be written or modified for supporting the controls.

Analyzing the Custom Controls

You can run an application containing the custom control and analyze the control from a UFT One perspective using the .NET Windows Forms Spy, the Keyword View, and the Record option. This enables you to see how UFT One recognizes the control without custom support, and helps you to determine what you want to change.

Using the .NET Windows Forms Spy

You can use the .NET Windows Forms Spy to help you develop extensibility for .NET Windows Forms controls. The .NET Windows Forms Spy enables you to:

View details about selected .NET Windows Forms controls and their run-time object properties.
See which events cause your application to change (to facilitate record and run extensibility implementation) and how the changes manifest themselves in the control's state.

You access the .NET Windows Forms Spy by choosing Tools > .NET Windows Forms Spy in the main UFT One window.

Note: To spy on a .NET Windows Forms application, make sure that the application is running with Full Trust. If the application is not defined to run with Full Trust, you cannot spy on the application's .NET Windows Forms controls with the .NET Windows Forms Spy. For information on defining trust levels for .NET applications, see the relevant Microsoft documentation.

For more information on the .NET Windows Forms Spy, see the UFT One Help Center.

When you plan the support for a specific control, you must ask yourself a series of questions. You can find a list of these questions in Using the .NET Add-in Extensibility Planning Checklist. When you are familiar with the questions and you are designing your own custom support classes, you can use the abbreviated, printable checklist.

Selecting the Coding Option for Implementing the Custom Servers

You can implement custom support for custom .NET Windows Forms controls in the following ways:

.NET DLL. Extends support for the control using a .NET Assembly.
XML. Extends support for the control using an XML file, based on a schema.

.NET DLL: Full Program Development Environment

Most Custom Servers are implemented as a .NET DLL. This option is generally preferred because:

Development is supported by all the services of the program development environment, such as syntax checking, debugging, and Microsoft IntelliSense.
If table checkpoint and output value support is needed, this support is available only when implementing the Custom Server as a .NET DLL.
A Custom Server implemented as a .NET DLL can perform part of its Test Record functions in the UFT One context and part in the context of the application being tested. For more information, see Using a .NET DLL to Extend Support for a Custom Control, and the API Reference.

For information on run-time contexts, see Selecting the Custom Server Run-Time Context Depending on the Test Function.

XML Implementation

There are circumstances when it is most practical to implement Custom Servers using the XML coding method. These circumstances include:

When the controls are relatively simple and well documented.
When the controls map well to an existing object, but you need to replace the implementation during a recording session (Test Record), or replace or add a small number of test object methods during a run session (Test Run).
When a full programming environment is not available–implementation using XML Custom Servers requires only a text editor.

However, when implementing a custom control with XML:

You have none of the support provided by a program development environment.
The XML implementation includes C# programming commands, and runs only in the Application under test context.

For more information, see Using XML Files to Extend Support for a Custom Control.

Selecting the Custom Server Run-Time Context Depending on the Test Function

Each Custom Server may implement the following test functions for each control:

Test Record
Test Run
Table Verification (to support checkpoints and output values)
A combination of these test functions

Run-time contexts include:

Application under test: The context of the application which is being tested.
UFT One: The UFT One context.

The following table provides guidelines for determining which test function you can implement for each run-time context.

Need / Task	Test Record	Test Run	Table Verification	Run-Time Context	Explanation
Create tasks using keyword-driven testing (and not by recording steps on an application)	Not applicable	Yes	Only for .NET DLL Custom Servers	Either Application under test or UFT One	The Test Record test function records the actions performed on the application being tested and the application's resulting behaviors. The recording is then converted to a test. If you plan to create GUI tests using keyword-driven testing, and not by recording steps on an application, you do not need to implement the Test Record function.
Implement the Custom Server in the Application under test context	Optional	Optional (usually)	Only for .NET DLL Custom Servers	Application under test	The Test Run function tests if the application is performing as required by running the test and tracking the results. Test Run is nearly always implemented in the Application under test context.
Listen to Microsoft Windows messages	Yes	Only with assistant classes	Only for .NET DLL Custom Servers	UFT One	If the .NET DLL Custom Server must both listen to Windows messages and access control events and properties, use assistant classes. The Custom Server running in the UFT One context can listen to events in the Application under test context with assistant class objects that run in the Application under test context. These objects also provide direct access to control properties.
Implement table checkpoints and output values on custom grid controls	Optional	Optional	Only for .NET DLL Custom Servers	Either Application under test or UFT One	You can implement support for table checkpoints and output values on custom grid controls, regardless of the context in which your .NET DLL runs.
Your application uses UFT One services more than it uses services of the custom control	Yes, but possibly less efficient	Possibly more efficient	Possibly more efficient	UFT One is preferred	There is no need to listen to Windows messages during a Test Run session, so the UFT One context is not required. However, if your application uses UFT One services more than it uses services of the custom control, it may be more efficient to implement Test Run in the UFT One context.

Analyzing Custom Controls and Mapping Them to Test Objects

When you develop .NET Add-in Extensibility, you map custom .NET Windows Forms controls to existing UFT One .NET Add-in test object classes and to Custom Servers that you develop.

The first mapping determines the test object class that UFT One uses to represent the custom control. The second specifies the Custom Server to use. The Custom Server extends the functionality of the test object that is used for the control to match the control's functionality.

If UFT One recognizes a .NET control out-of-the-box, and uses a .NET add-in test object other than SwfObject to represent it (for example SwfEdit or SwfList), then you cannot map this control to any other test object type. However, you can still map it to a Custom Server and extend the test object functionality.

Mapping Custom Controls to Test Objects

Map the custom controls to test objects by using the MappedTo attribute in the UFT One .NET Add-in Extensibility's System Windows Forms configuration file (SwfConfig.xml). Map each custom control to a UFT One test object class containing behaviors that are similar to those required to support your control.

If you do not specify a mapping, UFT One maps the custom control to the default generic test object, SwfObject. For more information on SwfConfig.xml, see Configuring UFT One to Use the Custom Server.

Note: Mapping is sometimes sufficient without any programming. If the existing UFT One test object adequately covers a control, it is sufficient to map the control to the UFT One test object.

Mapping Custom Controls to Custom Servers

When you map your control to a functionally similar UFT One test object, then, in your Custom Server, you do not need to override test object methods that apply without change to your custom control. For example, most controls contain a Click method. If the Click method of the existing test object implements the Click method of the custom control adequately, you do not need to override the existing object's method.

To cover the Test Run functionality of the custom object that does not exist in the existing object, add new methods in your Custom Server. To cover functionality that has the same method name, but a different implementation, override the existing object's methods.

If the UFT One test object adequately covers Test Record, but you need to customize Test Run, do not implement Test Record. If you do implement Test Record, the implementation replaces that of the existing object. You must implement all required Test Record functionality.

In UFT One, when you edit a step with the test object that you customized to support the custom control, the statement completion feature displays the custom properties and methods that you defined for the test object, in addition to those that exist in UFT One. UFT One uses test object configuration files to provide the list of custom test object methods and properties.

Where Do You Go from Here?

After you finish planning the custom control support, you create the .NET Add-in Extensibility support set. The topic Developing Your Support Set explains how to develop the .NET Add-in Extensibility support set.