Home • Corporate • Contacts •

TETware White Paper

Products

Solutions

Information

Datasheet

Documentation

FAQ

Knowledgebase

You are here: TETworks > White Papers > Other tools

Introduction

Using TETware to manage tests written in one of the programming languages which has a TETware API is fine, but what do you do if you want to use a third party test tool?  This article considers alternative strategies for using TETware with Mercury test tools.  We believe these principles  to hold true for other vendors test tools as well.

TETware offers users the flexibility to pursue one of three possible strategies for running Mercury tools under TETware control.  There is a Simple Solution, an Intermediate Solution, and an Advanced Solution.

Some of the principles here can also be found in Article 26 in the TETware Knowledgebase, "Writing a new API." 

Even with Mercury's GUI-based tools (WinRunner/Xrunner) you don't have to use their GUI - you can invoke them with command-line arguments, thus they can be run without user interaction.

A Simple Solution

A simple solution is to treat each invocation of a Mercury tool as a non-API conforming test case. If command-line arguments are required, these would have to be supplied by an exec tool script.

If you do this, you get TETware's ability to run a sequence of test cases from a scenario file, but the "result" of each test case (that is: each Mercury tool invocation) that appears in the TETware journal would be taken from the tool's exit status.

The TETware journal would not contain any journal information generated by the Mercury tool. You would have to look at the Mercury journal to find out the real result of each test.

An Intermediate Solution

Have TETware execute each Mercury tool invocation under the control of an API-conforming exec tool. The exec tool would execute the Mercury tool, then parse the Mercury journal and generate a temporary results file from that.

This exec tool probably wouldn't actually use a TETware API - it would just be a journal file translator - that is: it would write out a temporary results file which contains all the lines that would be generated by an API-conforming test case.

An Advanced Solution

A solution for advanced users who don't use Mercury's capture-replay capabilities but instead write their test cases in TSL from scratch.  Write a TETware TSL API - using the shell API as a guide to what flow-of-control is required.

 Article 26 in the TETware Knowledge Base ("Writing a new API") contains some hints on how to approach this task. 

Conclusion

TETware is flexible enough to offer a variety of solutions for the integration of third party test tools into TETware controller test suites.  Providing users with the flexibility to mix and match their tests according to their specific testing objectives.

References

When considering this issue, it is helpful to understand the following:

1. The difference between what TETware calls "API-conforming" and "non API-conforming" test cases. This is described in Chapter 2 of the TETware Programmers Guide.

2. The way in which tcc processes a test case in execute mode. This is described in "Execute mode processing" in Chapter 3.

To view this manual, or the knowledgebase please  click here.