Should suite/bin be placed in front of the other PATH
directories, or at the end? Doing this could effect the execution
of test suites; for example, if a test purpose issued an execvp()
to execute a program whose name conflicts with one of the tools.
Other than that, what you are saying could be done. Of course,
it would have to be documented and agreed on tetworks first.
back to index
The tools are obtained by searching the directories in the PATH
environment variable. Note that it is possible to specify the
full path of these tools to disable this search. For example,
TET_BUILD_TOOL=/my/local/bin/make
back to index
The TETware Issue 1 Design specification was completed 30 April 1996
and is available at http://tetworks.xopen.org/tet3spec.html.
back to index
The internal workings of the TETware tcc are completely different from
the tcc supplied with earlier TET versions.
One of the motivations of this change was to enable the functionality
provided by dTET2 and ETET to be integrated in a single product.
Another was to make it easy to add new directives and other
functionality to TETware, and to port it to other environments.
back to index
A requirement of our manufacturing people is for tcc to be able to
invoke repeated executions (eg for hardware stress testing) without
having to change the scenario files. Developers write the scenarios and
dont want repetitive execution. But manufacturing, who wish to reuse
the tests, do.
There are a couple of ways that you can do this using existing TETware
functionality.
Method (1) - if you know how many times the manufacturing people want
to repeat when you write the scenario.
You can provide more than one scenario when you write the
scenario file.
One scenario can list all the tests, and the other can repeat
the first the required number of times.
For example:
manufacturer
:repeat,100:^developer
developer
/ts/tc1/tc1
/ts/tc2/tc2
...
etc.
Your developers can use the scenario called "developer"
in the example above and the manufacturing
people can use the scenario called "manufacturer".
You can choose which scenario to execute on the tcc
command-line. For example, to execute all the tests in the list once:
tcc -ep test-suite-name developer
or to execute all the tests in the list 100 times:
tcc -ep test-suite-name manufacturer
Notes:
- If one of the scenarios in the file is called "all",
you don't need to use the
"test-suite-name scenario-name" style of syntax on the
tcc command-line.
- You can use :timed_loop: instead of :repeat: if your
manufacturing people would find this more helpful.
Method (2) - if you want to specify the number of times to repeat the
scenario on the tcc command-line.
In this method, you specify the basic scenario in a file and
add a :repeat: directive on the command-line.
The scenario file should contain the non-repeating list of
tests as in Method (1); for example:
developer
/ts/tc1/tc1
/ts/tc2/tc2
...
etc.
To execute all the tests once, you invoke tcc in the same way
as in Method (1); for example:
tcc -ep test-suite-name developer
You can specify both the -l and -s options to process a
scenario defined in a file under the control of a directive
specified on the command-line.
So, to repeat all the tests 50 times, you would say:
tcc -ep -s tet_scen -l ":repeat,50:^developer"
or, to repeat all the tests for (at least) 10 hours, you would
say:
tcc -ep -s tet_scen -l ":timed_loop,36000:^developer"
Notes:
- When you specify scenario lines using one or more -l
options, tcc processes the lines as if they were in a
scenario called "all".
So when you use -l and -s together, you can't have a
scenario called "all" in the file specified by the -s
option.
back to index
Not directly, however in conjunction with The Open Group's
Assertion Definition Language (ADL) tool this is possible.
See http://adl.opengroup.org
for more information.
back to index
