Test Script Console Adapter API |
To build a custom TSCA using TestManager's C/C++ API, you need the following skills:
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:
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.
TTConnect()
function when TestManager calls it.
TTGetTestToolOptions()
function when TestManager calls it.
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.
TTSetConfiguration()
and TTGetConfiguration()
.
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:
If the test scripts are organized in a flat list, you need the following functions to return data:
TTGetRoots()
TTGetNode()
If the test scripts are stored hierarchically, you need the following functions to return data:
TTGetRoots()
TTGetNode()
TTGetChildren()
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.
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.
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.
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.
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:
TTGetConfiguration()
This function prompts the user with a user interface that collects the information needed to configure the adapter. This function must return that information in a buffer so that TestManager can persist it with the test script source.
TTSetConfiguration()
This function enables TestManager to pass the test script source configuration information that is collected by TTGetConfiguration into the TSCA. The TSCA needs this information to know how to access the data in the test script source.
In summary, consider the type of test script source when deciding whether to provide configurability to the user.
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:
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:
Rational TestManager Extensibility Reference | Rational Software Corporation |
Copyright (c) 2003, Rational Software Corporation | http://www.rational.com support@rational.com info@rational.com |