Introduction to the Test Input Adapter API

prevnext

Building a Custom Test Input Adapter


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.


Prerequisite Skills

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


Building a TIA: Workflow and Implementation Issues

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:


Making a Connection

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.

  1. How can the TIA gain access to the test input data in the source? If an existing API performs this function, use it. If an appropriate API does not exist, is there a way to gain access to the data directly? Alternatively, is there a consistent way to export the data to CSV or some other common format for which an adapter exists or can be written?

  2. How can the adapter uniquely identify the test input source? If the test inputs are stored in a file, the preferred form of identification is the path to the file. If the test inputs are not stored in a file, you must create a logical name. The test input source identification that you develop is passed to the TIConnectEx() function when TestManager calls it.

  3. Is any additional information needed for connecting to the source? If not, the 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().

  4. How can the TIA uniquely identify a test input? If the tool used to create the test input supports the concept of a unique ID for each test input, it is optimal to use it. If not, the adapter needs to derive a unique identifier. Each test input needs its own unique ID per source, which is used as a key for association with a test case.

  5. Does the test input source require any configuration data in addition to the data needed for connection? If so, what data is needed? The major decision you face here is which data to hard code into the TIA itself and which data to have the user specify.

    For example, if you are building a general TIA to support general database access of test inputs, you can do one of the following:


Accessing the Data

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:

  1. What is the organizational structure for the test input data that the TIA will access? Is the data organized in a hierarchical structure or in a flat list?

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

  2. Are the items contained in the test input source all of the same type, or does the source support multiple types? A Rose model is an example of a test input source that contains many different types of test inputs.

  3. Is there an easily recognized bitmap or icon that represents the test input source?

    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.

  4. Are there easily recognized bitmaps or icons that represent the different elements that comprise test inputs in 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.


Supporting Impact Analysis

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.


Displaying Properties

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.


Supporting User Configuration of Test Input Data

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:

In summary, consider the variability in format of the test input source when deciding whether to provide configurability to the user.


Filtering

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.


Custom Action Support

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:


Registering a New Test Input Adapter

After you have implemented the Test Input Adapter and created the DLL file, do the following:

To register the DLL with TestManager:

  1. From TestManager click Tools > Manage > Test Input Types.

  2. Click New in the Manage Test Inputs dialog box. (If the button is disabled, you do not have write privileges. See the Using the Rational Administrator manual or Help.)

  3. Enter the path to the DLL in the space provided for the adapter.

  4. Click the Sources tab.

  5. Click Insert.

  6. If a message appears asking if the type should be created, click Yes.

  7. In the New Test Input Source dialog box, enter a name of the source (40 characters maximum).

  8. Enter a description.

  9. Select an owner from the list.

  10. In the Connect Information field, enter the connection information required for this test input source.

  11. Click OK.

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.


prevnext


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