Home Corporate Contacts

TETware Knowledgebase


Products
Solutions

Information

Datasheet
Documentation
FAQ
Knowledgebase

Return to Knowledgebase Index

3. How does TETware handle the tet_xres temporary results file?

If the test case is a distributed API-conforming test case, then the API must use tetxresd (the execution results daemon) for the journal. Otherwise, the API may either use tetxresd or generate its own tet_xres file (but not both!).

In this context:

  1. distributed means that either


    1. the :distributed: scenario directive is used; or


    2. the :remote: scenario directive is used and system 0 is included in the system list


  2. API-conforming means that either


    1. TET_API_COMPLIANT is true; or


    2. TET_API_COMPLIANT is unset and TET_OUTPUT_CAPTURE is false




The TETware tcc looks for a tet_xres file in the test case execution directory when an API which does not support distributed testing is used. (Currently: all the APIs except the Distributed C and C++ APIs.)

All the journal processing is performed by tcc. tccd is only used when a tet_xres file is on a remote system, and then only to copy it to the local system for processing by tcc.

 

Implementation details

Journal processing is performed by one of the functions in tcc's execution engine. This function is called tcs_journal() in file tcc/proctc.c. A large comment in the code describes the strategy that is used; it reads as follows:


/*
** for an API-conforming test case:
**	if there is a journal at this level:
**		if the tool used XRESD:
**			process the XRESD file;
**		otherwise:
**			the tool should have used tet_xres;
**			if there are child proctabs:
**				process each child's tet_xres file;
**			otherwise:
**				process this level's tet_xres file;
**	otherwise:
**		for each child journal:
**			if the tool used XRESD:
**				process the XRESD file;
**			otherwise:
**				the tool should have used tet_xres;
**				process the tet_xres file;
** otherwise:
**	if there is a journal at this level:
**		if PRF_AUTORESULT is set (i.e., non-API in EXEC mode):
**			generate a TP result from pr_exitcode;
**	otherwise:
**		for each child journal:
**			if PRF_AUTORESULT is set:
**				generate a TP result from pr_exitcode;
**
*/
Note that the words ``test case'' and ``tool'' are used interchangeably - tcc processes test cases and tools in the same way.

In the simple case of an API-conforming test case running on the local system, tcs_journal() calls jnlproc_api() which is in file tcc/jnlproc.c.

A combined execution results file is always opened (by tetxresd) for an API-conforming test case before the test case is processed. However, this file will remain empty unless an API that supports distributed testing is used. The code in jnlproc_api() looks at the combined execution results file to see if there is anything there, and uses it if there is. Otherwise, jnlproc_api() assumes that another API has been used and looks for the tet_xres file instead. In the simple case, this processing is performed by a call to jp_tetxres(), which opens the file. Once the tet_xres file is opened, a call to jp_xres() transfers the contents of the file to the journal.

 

See also

  • "Test reporting and journaling'' in the TETware Programmers Guide.

  • "Simple TETware architecture diagrams'' and "The Execution Results Daemon tetxresd'' in the TETware User Guide.

 


Home Contacts Legal Copyright Corporate News

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