Return to Knowledgebase Index
26. Writing a new API
One of the requirements that I have is to create an API for an internal language we have developed. Can you suggest what are the requirements for creating such an API? The API will allow for remote execution, but distributed execution is not required. Do you have any pointers? What is the magnitude of such an effort?
When you create a new API for TETware, the first thing to consider is: Can the new API language be linked to C?
If the answer is Yes, then the task is a relatively simple one. You can provide a glue layer between the new language and the existing C TCM and API library. When you define the way in which test cases are to be called by the TCM, you will probably need to use the dynamic test case interface that is described in Chapter 8 of the TETware Programmers Guide. (If you go down this route, be sure not to use unpublished interfaces in the C TCM or API since these can and do change between TETware releases!)
However, if the answer is
there is a little more work to do.
You have to implement your own TCM and API library.
If your language is an interpreted one
it is probably best to use the (Bourne) Shell API as a
You can find the source code for this below the directory
If you want to see an example of how the Shell API is used, check out
the Shell API demonstration test suite which is below the
If no arguments are passed on the command line, your TCM should behave
Your TCM should allow for the possibility that an IC might be specified more than once on the command line.
However, it is also possible for your test case to be invoked directly by a user, so you should allow for the possibility that these environment variables are not set. Look at the Shell API to see how it handles this situation.
The TCM should create a results file called
Your TCM should exit with a zero status value if no errors occur. If a fatal error occurs you should print a Test Case Manager message describing the problem to the execution results file and exit with a +ve status value.
As far as possible, your API should (at least) provide functionality of each type that is described in Chapter 11 of the TETware Programmers Guide. Depending on the capabilities of your language, you may need to provide explicit functions to implement the things that the Shell does of itself - these things are described in the last few subsections of Chapter 11. You can refer to the corresponding sections in Chapter 8 for more information if necessary.
One point to note - the description of the Shell version of
These are described in Chapter 13 of the TETware User Guide and in Appendix C of the TETware User Guide.
Your TCM and/or API should generate the following lines at the appropriate times:
All the other line types are generated by
You should ensure that each test purpose only generates one Test Purpose Result line, no matter how many times your