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.

Back to top

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.

Back to top

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.

Back to top

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.

Back to top

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.

Back to top

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.

Back to top

See also: