Introduction to the Test Input Adapter API |
This section first describes the skills you need to build a custom TIA and then describes the implementation issues that arise when you create this adapter.
To build a custom TIA using the TestManager C/C++ API, you need the following skills:
This section discusses the general workflow that you should follow when building a TIA and the implementation issues that arise at each phase of this workflow. The phases are as:
The most critical phase in developing a TIA is determining how to use the functions in the Data Access group to access the data (that is, the test inputs 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 file, a database, or some other source.
It is most efficient if the TIA maintains an active connection to the test input source rather than reconnecting each time the user makes a request from TestManager. It is possible that some test input sources do not require a connection to access the test inputs contained within it.
Given these considerations, you, the TIA developer, must determine the answers to the following connection issues at the beginning, before you create the TIA. The decisions you make regarding the connection issues are the most critical decisions you make in the process of building the TIA. Once you have determined satisfactory solutions to the following issues, you are likely to be successful in your development of the TIA.
TIConnectEx()
function when TestManager calls it.
TIConnect()
function is probably adequate. If, however, additional data is needed, the user can specify it as connection options when registering the test input source. These connection options are passed to TIConnectEx().
For example, if you are building a general TIA to support general database access of test inputs, you can do one of the following:
The first option, while requiring less initial work on your part, is not reusable when the test input configuration changes -- for example, a new table is used to store the test input data. In this case, you would have to write a new TIA for the new table.
The second option, in which you write the TIA so that the user can specify the table and column names, is more flexible and reusable. To enable the user to specify this information, you must implement the functions TISetConfiguration()
and TIGetConfiguration()
. TIGetConfiguration() must provide a UI to collect the configuration information.
The next phase in building a TIA is to develop support for the functions in the Data Access group.
Once this support is developed, the TIA should be ready for partial use by TestManager. If a new test input type has been registered to use the TIA, the user should be able to:
The issues to resolve in developing support for functions in the Data Access group are:
If the test input data is organized in a flat list, you need the following functions to return data:
Because Windows users are accustomed to recognizing software components by icons, you should support the function TIGetSourceIcon()
. This function returns the path of the bitmap that represents the test input source.
Because Windows users are accustomed to recognizing software components by icons, you should support the function TIGetTypeIcon()
. This function returns the path of the bitmap that represents the node type.
A key TestManager feature is its ability to support impact analysis based on changes to test inputs. For this feature to work, you must implement the function TIGetModifiedSince()
, which returns a list of test inputs that have been modified since a specified date and time. To determine which test inputs have changed, the TIA needs to access a test input source containing a last-modified date/time for each test input. Without such a source, it is unlikely that you can create a TIA that supports impact analysis.
By default, the only test input information displayed by the TestManager user interface is the input name. To enable the user to view other associated data about the test input from the TestManager user interface, you should implement the function TIShowProperties()
. Try to use the underlying tool's property sheet if it is appropriate for display and can be called by the TIA.
In designing a TIA, you need to decide whether to implement the TIA in a way that enables the test designer to specify how the adapter should interpret the test input data. If the test designer can specify data interpretation, you must determine the kind of user interface to provide for specifying the configuration.
You may want to support user configuration of test input data because test inputs from different sources vary in data access, data format, and data stability.
For example, test inputs from a RequisitePro project are relatively stable. The built-in Test Input Adapter is hard coded to understand the configuration of RequisitePro projects. Therefore, the test designer does not need to specify a configuration to the adapter.
In contrast, a test input type can be highly variable. For example, the data configuration in a Microsoft Excel spreadsheet is variable, and therefore the TIA does not intrinsically understand this data configuration, such as whether the data is arranged horizontally or vertically. Given the variable nature of test inputs, you cannot build a specialized adapter for each possible condition.
To enable user configuration of test input data, you should implement the following functions:
TIGetConfiguration()
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 input source.
TISetConfiguration()
This function enables TestManager to pass into the TIA the test input source configuration information found in the buffer. (The content of this buffer is the same as the configuration information collected from the user.) The TIA needs this information to know how to access the data in the test input source.
In summary, consider the variability in format of the test input source when deciding whether to provide configurability to the user.
A test input source can contain an enormous number of test inputs. For example, a RequisitePro project can have 10,000 or more requirements, each of which is a possible test input. In cases like this, you must provide filtering support so that only test inputs meeting certain criteria are displayed to the user in Test Input view or in test case distribution reports. If the test input is created in a tool that supports filtering, you should take advantage of it.
If you implement the functions TISetFilterEx()
and TIGetFilterEx()
, TestManager can set and get a filter.
TestManager enables you to expose operations in the GUI that are useful for the test designer when working with test inputs. For example, a test designer working with a Requisite Pro project as a test input source would probably want to carry out an operation that opens the Requisite Pro project.
You, the adapter writer, can build the adapter so that the test designer can execute an operation to open Requisite Pro from the GUI. You can also support custom operations for specific test inputs.
To support custom actions against the Test Input source, implement the following functions:
To support custom actions against a test input, implement the following functions:
After you have implemented the Test Input Adapter and created the DLL file, do the following:
__cdecl*
calling convention.
To register the DLL with TestManager:
You can also edit, rename, copy, and delete a test input source from the Manage Test Input Types dialog box.
For detailed information about managing extensible test inputs, see the TestManager online Help.
Rational TestManager Extensibility Reference | Rational Software Corporation |
Copyright (c) 2003, Rational Software Corporation | http://www.rational.com support@rational.com info@rational.com |