RUN_TEST_STEP
TEF parameters are used with the RUN_TEST_STEP
command to
perform special checks on the current environment or on the results of the
test.
Syntax
RUN_TEST_STEP [TEF parameters] <TimeoutSeconds>
<xxxServerFriendlyName> <StepName> [FullFilePath\xxxFile.ini]
[IniSection]
Executes StepName
in xxxServerFriendlyName
using a user defined xxxFile.ini
file and the data in section
IniSection
with guard TimeoutSeconds
.
Note: If your system drive is other than C:
drive, use the SYSDRIVE
variable with the absolute file path to
point to the system drive.
RUN_TEST_STEP [TEF parameters] <TimeoutSeconds>
<xxxServerFriendlyName> <StepName>
[${SYSDRIVE}\FullFilePath\xxxFile.ini] [IniSection]
-
TimeoutSeconds
: It is the timeout value in decimal. If
the test step is still executing when this value is reached, the framework
terminates test step execution. A value of –1 disables the guard timer. A guard
timer is used to check if the test or the program does not continue after the
mentioned period of time in seconds.
-
xxxServerFriendlyName
: It is the human readable name
for the CTestServer
derived class, set up during class
initialisation.
-
StepName
: It is the human readable name for the
CTestStep
derived class, set up during class construction. The
test step shall set the result of its execution to one of the
TVerdict
result codes. See Result Codes for details.
-
IniSection
: It is the name of the section within the
ini
file. The test step reads the operational parameters from this
section.
FilePath\xxxFile.ini
is the full path and filename of
a .ini
file.
TEF parameters
A range of parameters can also be used, either individually or combined
with one or more of the available options. The TEF parameters are case
sensitive. The following table lists the TEF parameters and their description:
Parameter | Description
| Usage |
---|
!Error
|
This is used to check whether a test has failed with a specific
error code. If the error matches then the TEF result is set to pass.
|
RUN_TEST_STEP !Error=-43 100 SampleServer SampleStep
|
!PanicString
|
This is used to check whether a test step has performed a panic
and that the panic string matches the value passed in.
|
RUN_TEST_STEP !PanicString=ExpectedPanic 100 SampleServer
SampleStep
|
!PanicCode
|
This is used to check that a test step has performed a panic and
that the panic code matches the value passed in. !PanicString and
!PanicCode replaces the deprecated
RUN_PANIC_STEP_RESULT command.
|
RUN_TEST_STEP !PanicCode=1 100 SampleServer SampleStep
|
!Result
|
Compares the expected result and the actual result to set the
overall result for the test step. It expects one of the TEF
TVerdict result codes to be passed back from the test step.
This replaces the RUN_TEST_STEP_RESULT command that
is deprecated.
|
RUN_TEST_STEP !Result=Fail 100 SampleServer SampleStep
|
!Heap
|
Allows the heap size to be allocated for thread in which the test
step is executed.
The allowed range for heap size values are between 0x100 and
0x100000. Values not between these ranges will be set to a default value of
0x100000.
|
RUN_TEST_STEP !Heap=0x100000 100 SampleServer SampleStep
|
!OOM
|
Forces the step execution to run in an OOM environment. The cell
usage is tested before and after each test run to ensure that no memory leak
occurs. The test will complete with a success when all of the heap allocations
within the test have been tested and no memory has been leaked. If at any point
there is a memory leak, the test will panic and the loop iteration along with
panic details will be logged.
|
RUN_TEST_STEP !OOM 100 SampleServer SampleStep
|
!Setup
|
This parameter allows a single integer value to be passed to a
test step. The value is retrieved within the test step using
GetSetupState() and is typically used to select from a list of
enumerated options. For information on GetSetupState() , refer to
Using Setup Parameter Values in Test Steps.
|
RUN_TEST_STEP !Setup=5 100 SampleServer SampleStep
|
Note: The !OOM
parameter checks that memory
allocated in a doTestStepPreamble()
function is deallocated in the
corresponding doTestStepPostamble()
function. Any memory allocated
within a doTestStepL()
function, however, must be deallocated
before the function returns to avoid a memory leak being indicated.