Home Corporate Contacts

TETware FAQ


You are here: TETworks > TETware FAQ Index > FAQ

TET APIs


A1. What APIs are available to write tests in?

The following APIs are available in TETware:

  • C
  • C++
  • Perl
  • XPG3 Shell
  • Korn Shell
  • Tcl
  • Java (* in JETpack, native in TETware 3.4)

back to index


A2. Are there any examples of tests written using the different APIs?

Yes, TETware includes a distributed demo with the source, see chapter 4 of the TETware Users Guide for instructions.

The user contributed distribution (contrib) with TETware also includes sample test suites (for C, C++, Java, perl, tcl, shell and ksh), including test templates.

back to index


A3. Can I get more information on writing tests?

The TETware Programmer's Guide contains comprehensive reference information for the supported TETware Application Programming Interfaces. The Open Group's training courses include as an underlying theme how best to use TETware for test development.

back to index


A4. What are the system requirements for Java support?

The Java API requires a JNI-capable Java development kit installed (JDK1.1 or later). It expects the Java utilities "java", "javac", "jar" and "javah" to be in accessible from your PATH.

TET_ROOT should be defined and point to the TET installation.

TET_ROOT/bin should be in the execution PATH when running tests.

The Java API is supplied as a fully supported integrated API in TETware 3.4, and as the JETpack add-on for TETware 3.1, 3.2 and 3.3.

back to index


A5. Can you use the Java API to test a GUI based test case, or a test case using Netscape IFC.

Yes, the Java API has no restriction regarding the Java classes you use.

back to index


A6. Has TETware been used with tcl and/or expect?

Yes, TETware includes a TCL API and demo in its user contributed distribution (contrib).

back to index


A7. Are there any sample build tools that use the TETware API?

Yes, see the C api demonstration test suite within the TETware contrib distribution. This uses a tool called build tool that front-ends make, and is able to pass test configuration variables to make in the environment. This is an API conforming tool, and upon failure it puts the output from make into the journal.

back to index


A8. Are there a  report writer?

TETware Support customers receive a Report Writer.  TETware GUI Users also receive a database driver.

back to index


A9. How do I run a debugger on tests run using tcc?

The TET_EXEC_TOOL configuration variable provides a general-purpose hook which enables you to run test cases under the control of another program; for example:

tcc -pe -vTET_EXEC_TOOL=mydebugger -l/tset/area/mybuggytest{1}

It is described in the sections entitled "Execute mode processing" and "Configuration variables which modify TETware's operation", both in the TETware Programmers Guide.

If your debugger can be invoked from the command line, you can set TET_EXEC_TOOL in the execute mode configuration to the name of your debugger. Additional arguments to the debugger may be assigned to the TET_EXEC_FILE configuration variable.

If you do this, when tcc processes each test case in execute mode it executes the following command:

TET_EXEC_TOOL TET_EXEC_FILE test-case-name ic-list

This command is executed in the test case execution directory.

This method works as described with TETware-Lite. If you are using Distributed TETware it is not possible to interact with test cases and tools directly from the terminal where tcc is invoked, since test case parts are not children of tcc.

If your debugger has a command-line interface (such as sdb or gdb), it is necessary to use a top-level exec tool to attach the test case to another terminal in order to allow for user interaction with the debugger. You can do this by using tet_start which is included in the TETware 3.3 distribution.

This tool is described in Chapter 8 of the TETware User Guide.

back to index


A10. Which debuggers do you support with TETware?

We do not provide specific support for particular vendor's debuggers, other than that provided through the mechanism that described above.

The key issue is: if the debugger can be invoked from the command line (either directly or via some script), then it should be possible to use it to debug test cases; otherwise, it can't be used.

back to index



Home Contacts Legal Copyright Corporate News

Copyright © The Open Group 1995-2012, All Rights Reserved