Test Script Console Adapter API

prevnext

Building a Custom Test Script Console Adapter


This section describes:


Prerequisite Skills

To build a custom TSCA using TestManager's C/C++ API, you need the following skills:


Building a TSCA: Workflow and Implementation Issues

This section discusses the general workflow that you should follow when building a TSCA and the implementation issues that arise at each phase of this workflow. The phases are:


Making a Connection

The most critical phase in developing a TSCA is determining how to use the functions in the Data Access group to access the data (that is, the test scripts stored in a source) and return this data to TestManager. In most cases, the data is accessed using a common API or directly by accessing the physical representation of the data. This physical representation can be a file, a database, or some other source.

To work efficiently, the TSCA should maintain an active connection to the test script source rather than reconnecting each time the user makes a request from TestManager.

Given these considerations, you, the TSCA developer, must determine the answers to the following connection issues at the beginning, before you create the TSCA. The decisions you make regarding the connection issues are the most critical decisions you make in the process of building the TSCA. Once you have determined satisfactory solutions to the following issues, you are likely to be successful in your development of the TSCA.

  1. How can the TSCA gain access to the test scripts in the source? If an existing API performs this function, you should probably use it. If an appropriate API does not exist, is there a way to gain access to the data directly?

  2. How can the adapter uniquely identify the test script source? If the test scripts are stored in the file system, the preferred form of identification is the root path to the files. The test script source identification that you develop is passed to the TTConnect() function when TestManager calls it.

  3. Is any additional information needed for connecting to the source? If so, you should specify that information as a connection option when registering the test script source. The connection options are passed to the TTGetTestToolOptions() function when TestManager calls it.

  4. How can the TSCA uniquely identify a test script? If the tool used to create the test script has a feature that is analogous to a unique ID, it is optimal to use this feature.

    Note: Each test script must have its own unique ID for each test script source, because that identifier is used to associate test cases with it.

  5. Does the test script source require any configuration data in addition to the data needed for connection? If so, what data is needed? In developing solutions to these issues, you should implement the functions TTSetConfiguration() and TTGetConfiguration().


Accessing the Data

The next phase in building a TSCA is to develop support for the needed functions in the Data Access group.

Once this support is developed, the user should be able to do the following after a new test script type has been registered to use the TSCA:

The issues to resolve in developing support for needed functions in the Data Access group are as follows:

  1. What is the organizational structure for the test scripts that the TSCA accesses? Is the data organized in a hierarchical structure or in a flat list?

    If the test scripts are organized in a flat list, you need the following functions to return data:

  2. Are the items contained in the test script source all of the same type? Are they all valid implementations that can be executed? (Examples of items that cannot be implemented are verification points and low-level test scripts contained in Rational Robot® GUI test scripts.) Even if certain items cannot be executed, you may want to make them visible to TestManager by implementing the following functions:

  3. Is there an easily recognized bitmap that represents the test script source?

    Because Windows users are accustomed to recognizing software components by icons, you should support the function TTGetSourceIcon(). This function returns the path of the bitmap that represents the test script source.

  4. Are there easily recognized bitmaps that represent the different elements comprising test scripts in the test script source?

    Because Windows users are accustomed to recognizing software components by icons, you should support the function TTGetTypeIcon(). This function returns the path of the bitmap that represents the test script node.


Integration with Source Control

To support integration with source control, TestManager needs the TSCA to support the following functions:

You must decide which files need to be placed under source control.


Displaying Properties

By default, the only test script information displayed by the TestManager user interface is the test script's name. If you want to enable the user to view other associated data about the test script, implement the function TTShowProperties(). If possible, use the underlying tool's property sheet if it is appropriate for display and can be called by the TSCA.


Supporting User Configuration of the Test Script Source

The formats of different test script sources vary as to how the adapter accesses the information in them. For example, if test scripts are stored in a database, the test scripts may be stored in different tables for different test script sources.

Therefore, you may want the TSCA to provide a GUI that enables the user to provide configuration information when registering the test script source. By specifying configuration data, the user is informing TestManager about how to locate and identify the desired test scripts in the test script source.

If you decide that you need to provide this configuration ability to the user, you must decide:

Thus, when the test script sources are highly variable, write the TSCA to display a GUI that enables the user to specify the test script storage configuration and communicate it to TestManager. To enable this functionality, implement the following functions:

In summary, consider the type of test script source when deciding whether to provide configurability to the user.


Filtering

If a test script source contains an enormous number of test scripts, you should provide filtering support. Filtering enables the user to use the Test Script view to selectively view the test scripts in the test script source. If the test script is created in a tool that supports filtering, take advantage of it.

If you implement the following functions, TestManager can use filtering in the Test Script view:


Custom Action Support

TestManager enables a TSCA to expose operations in the Test Script view that the test designer can use when building test scripts. For example, a test designer working with a Robot test script as a test script source would probably want to carry out an operation that opens the Robot application.

You, the adapter writer, can build the adapter so that the user can implement an operation to open Robot from the GUI. You can also support custom operations for specific test scripts.

To support custom actions against a test script source, implement the following functions:

To support custom actions against a test script, implement the following functions:

prevnext


Rational TestManager Extensibility Reference Rational Software Corporation
Copyright (c) 2003, Rational Software Corporation http://www.rational.com
support@rational.com
info@rational.com