Understanding How to Implement .NET Add-in Extensibility

You implement .NET Add-in Extensibility support for a set of custom controls by developing a .NET Add-in Extensibility support set. Developing a .NET Add-in Extensibility support set consists of the stages described below.

Plan the custom support set

Detailed planning of how you want OpenText Functional Testing to recognize the custom controls enables you to correctly build the fundamental elements of the .NET Add-in Extensibility support set. Generally, to plan the support set, you:

  • Determine the .NET Windows Forms controls for which you need to customize support.

  • Plan the test object model by determining which test objects and operations you want to support based on the controls and business processes you need to test.

  • Plan the most appropriate way for implementing the support.

For more information, see Planning Your Support Set.

Back to top

Develop the custom support set

To develop a .NET Add-in Extensibility support set, you must perform the following tasks:

These activities are described in detail in the following sections.

Back to top

Define The Test Object Model

Introduce the test object model that you want OpenText Functional Testing to use to test your applications and controls. The test object model is a list of the test object classes that represent custom controls in your environment, and their test object methods.

You define the test object model in a test object configuration XML file. For more information, see Describing the Test Object Model .

Create Custom Servers

Create a Custom Server (DLLs or control definition XML file) to handle each custom control. In the Custom Server, you can modify:

  • What steps are recorded during a recording session.

  • The implementation of test object methods.

  • Support for table checkpoints and output values.

The Custom Server mediates between OpenText Functional Testing and the .NET application. During a recording session, the Custom Server listens to events and maps the user activities to meaningful test object methods. During a test run, the Custom Server performs the test object methods on the .NET Windows Forms control.

Custom Server Coding Options

The Custom Server can be implemented in one of the following coding options:

  • .NET DLL

  • XML, based on a schema (which OpenText Functional Testing then uses to create a .NET DLL Custom Server behind the scenes)

For more information, see:

Custom Server Run-time Contexts

Classes supplied by a Custom Server may be instantiated in the following software processes (run-time contexts):

  • Application under test context: An object created in the context of the application you are testing has direct access to the .NET Windows Forms control's events, methods, and properties. However, it cannot listen to Windows messages.

  • Testing tool context: An object created in the testing tool context can listen to Windows messages. However, it does not have direct access to the .NET Windows Forms control's events, methods, and properties.

If the Custom Server is implemented as a .NET DLL, an object created under the testing tool can create assistant classes that run under the application you are testing.

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

For more information on assistant classes, see Using a .NET DLL to Extend Support for a Custom Control and see the OpenText Functional Testing .NET Add-in Extensibility API Reference.

Back to top

Map the Custom Controls to the Relevant Test Objects

Map test objects using the .NET Add-in Extensibility configuration file (SwfConfig.xml). This file is located in the <OpenText Functional Testing installation path>\dat\ folder and contains:

  • The mapping of the custom controls to their corresponding test objects.

  • The mapping to corresponding Custom Servers. This mapping provides the full functionality to OpenText Functional Testing test objects.

For more information, see Mapping Custom Controls to Test Object Classes.

The illustrations below demonstrate how .NET Add-in Extensibility maps custom controls to their test objects and Custom Servers during recording sessions and run sessions.

How OpenText Functional Testing Maps Custom Controls to Test Object Classes During Recording

The following illustration and table explain how OpenText Functional Testing maps custom controls to their test objects, locates the corresponding extended implementation for the custom control, and records an appropriate test step when recording.

   

Step

Description

1

An event occurs on a type of control that OpenText Functional Testing does not recognize, or for which recording implementation is customized.

2

OpenText Functional Testing checks the Type attribute of the Control elements in the SwfConfig.xml file to locate information for this type of custom control. OpenText Functional Testing then checks the MappedTo attribute, to find the test object class mapped to this type of control. If no specific test object class is specified, SwfObject is used.

3

OpenText Functional Testing checks the DLLName element in the SwfConfig.xml file to locate the Custom Server containing implementation for this type of custom control, and communicates with the Custom Server.

4

The Custom Server instructs OpenText Functional Testing what step to add to the test in response to the event that occurred.

How OpenText Functional Testing Maps Custom Controls to Custom Servers When Running a Test

The following illustration and table explain how OpenText Functional Testing maps custom controls to their test objects, locates the corresponding extended implementation for the custom control, and performs the appropriate operations on a custom control when running a test.

   

Step

Description

1

A test runs. This test includes a test object representing a custom control whose implementation has been customized.

2

OpenText Functional Testing locates the Control element in the SwfConfig.xml file that contains information for the custom control mapped to this test object.

3

OpenText Functional Testing checks the DLLName element in the SwfConfig.xml file to locate the Custom Server containing implementation for the custom control.

4

OpenText Functional Testing runs the test using the correct implementation for the test object operation as defined by the implementation of the custom control.

Back to top

Configure and deploy the custom support set

To deploy your .NET Add-in Extensibility support set and enable OpenText Functional Testing to support your controls, copy the files you created to specific locations within the OpenText Functional Testing installation folder.

For more information, see Configuring the Custom Support Set.

Back to top

Test the custom support set

After you have created the .NET Add-in Extensibility support for your controls, test your .NET Add-in Extensibility support set.

You can learn how to develop a .NET Add-in Extensibility support set hands-on, by performing the lessons in Tutorial: Simple Custom .NET Windows Forms Control and Tutorial: Complex Custom .NET Windows Forms Control.

Back to top