TOPIC:

Hi,

For those, who worked with visual languages, and are familiar with forms, components, etc. it is known that during runtime execution objects on the form my be accessed through structures like e.g.:

components[componentindex: integer]

The above structures are available from a code and allow easy iteration through all objects of different types and an access to objects properties.
In TTCN-3 we also have test components, ports, testcases, lists of defaults (which in reality do not exist, it is only concept of default handling). Usually they are defined by the user and handled as single references. When user declares an array and references are grouped in an array, they can be easily accessed, e.g. an array of verdicts, an array of defaults. The advantage of this solution is possibility of setting an own order of elements. The disadvantage is necessity of objects actualization during testcase execution, e.g. from an array of PTCs those terminated should be removed.

It is also known that test system running test suite should handle its own structures like: lists of test components, lists of defaults, lists of test cases, etc.
The internal representation is unknown for us and may be different /tool manufacturer dependent/ but why not to give an access to the user for a standardized test system structures interface?
There is a simple and dirty proposal below for presentation of the idea only so forgive me for the errors.

---

27.6 TTCN-3 runtime information


TTCN-3 runtime structures handled by test system may be used to facilitate test suite design in more efficient manner.

A large number of predefined structures describing test system objects can be accessed from TTCN-3 statements. These structures are handled by test system while test cases execution and can be accessed from test suite code. Test system provides variables handling actual size for each array of objects.



All test cases defined in a TTCN-3 module are accessed in a control part through testcases[integer index] array. The number of test cases defined in a TTCN-3 module is returned by testcasecount variable. An array of test cases can be indexed from 0 value through testcasecount - 1 value.



Each testcases[] array element is a record defining testcase properties.

The "name" field returns unique testcase name.

The "verdict" field returns actual verdict of testcase.

The "parameters[]" array returns array of parameters passed to testcase of anytype type.




All definitions may be already included in a system predefined files:



var integer testcasecount; // variable provided by the test system



type record SuiteTestCase {

charstring name;

charstring group;

verdicttype verdict; // actual test case verdict

integer testcaseparcount; // read-only data provided by the test system

anytype parameters[testcaseparcount]; // parameters table for a testcase

}



type SuiteTestCase testcases[testcasecount];



All test components defined in a TTCN-3 module are accessed in a control part through components[integer index] array. The number of test components defined in a TTCN-3 module is returned by componentcount variable. An array of test cases can be indexed from 0 value through componentcount - 1 value.



Each components [] array element is a record defining test component properties.

The "name" field returns unique test component name.

The "ports[]" array returns array of declared component ports created while test component creation, each of port type.

The "defaults[]" array returns array of activated defaults for a test component, each of TestComponentDefault type.



All definitions may be already included in a system predefined files:



var integer componentcount; // variable provided by the test system



type record TestComponentDefault {

charstring altstepname;

anytype ref; // reference to an activated default

// which is used in deactivate statement

}



type record TestComponent {

charstring name;

integer portcount; // read-only data provided by the test system

integer defaultcount; // read-only data provided by the test system

verdicttype verdict; // actual test component local verdict

port ports[portcount]; // ports table for a test component

TestComponentDefault defaults[defaultcount]; // defaults table for a test component

}

// property mtc;

// property self;

// etc ...






type TestComponent components[componentcount];

---

EXAMPLE: Execute all test cases via simple loop (testcases without parameters, for parameters sth. else may be introduced, open arrays, etc.)

for (j:=1; j<=testcasecount; j:= j+1)

{ execute(testcases[j-1].name) }


EXAMPLE: Execute selected test cases for a given group:
// this example shows another problem, is it possible to remove parentheses if compound statement is embedded in another compound statement, like in other languages?

for (j:=1; j<=testcasecount; j:= j+1) {



if testcases[j-1].group == "ABM_State" {

if execute(testcases[j-1].verdict) != true {

log( testcases[j-1].group + '/' + testcases[j-1].name + ' verdict: ' + 'not true' )

}

}

}

// verdict different from true may be an error, inconc, false, none, but I should check return value if equal to each of verdicts just to know how to formulate an output string, it may be done more easily: if logging of verdicts is used maybe function verdicttostr(verdicttype verdict): charstring would be useful?





EXAMPLE: Verdicts always stored, always accessed via testcases[testcaseindex].verdict, where testcaseindex in range 0 .. testcasecount-1.

EXAMPLE: Defaults finally may be accessed through a list, like described in a standard:

components[componentindex].defaults[defaultindex]


An access to defaults from current component, where 'ref' is a default handle, the name may be different:

self.defaults[defaultindex].ref

There also may be an access to default reference, used altstepname and parameters used while activation of a default

// Another question is if all structures accessed as read-only or any modifications allowed?
// Maybe such structures would change a little bit operations on objects and TTCN-3 would be standardized as in OO languages, with properties, methods, procedures, e.g.

object.property
object.method
object.procedure

EXAMPLE: Method 'deactivate':

for (j:=1; j<=self.defaultcount; j:= j+1) {

self.defaults[j-1].deactivate; // may be in the future
deactivate(self.defaults[j-1].ref); // may be now when using structures
}

// maybe TTCN-3 needs 'with' statement to be used to access references more easily, e.g.:

with self do {
for (j:=1; j<=defaultcount; j:= j+1) {

defaults[j-1].deactivate;
deactivate(defaults[j-1].ref);
}
}


EXAMPLE: Something like 'all port.stop' may be replaced by:

self.ports.stop;


which may be an example of method use, when ports are defined as an object embedded in each component / property of each component.



The number of examples is infinite so this was the latest one.
And most people does not like large posts like this one :-)

Best Regards,
Mariusz Kupiec