ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
A very common pattern is:
t.start;
t.timeout;
Almost nobody expects default alternatives to be evaluated when checking for the timeout. But, if some default alternative like
alt { [] p.receive { repeat } }
is active, this will read all messages from the port p while waiting for the timeout (which might carry significance for the rest of the testcase).
Another of those patterns is
comp.start(..)
comp.done;
A similar problem is if there are multiple channels of communication like the sync communication between components or upper tester communication.
In such instances, while waiting for the answer on port p1, default alts reading messages from another port can influence the test result negatively.
A possible way to deal with this problem is to add boolean component variables and use them for all guards in default alternatives that should not be active all the time. It is then necessary to set/unset these flags before every alt statement.
Of course, this requires a lot of additional code and is very error prone if the number of flags gets bigger and possibly needs to be amended whenever a new default alternative is added to the testcase.
Ideas to address this problem:
1)
Default alternatives should be added a category upon activation and alt statements should allow giving one (or maybe a list) of such categories whose defaults should be active.
2)
For simple non-port alternatives (short form without syntactically enclosing alt like given above), normal defaults should either never be active (unless they are marked specially upon activation) or some modifier @nodefault could be placed in front of them to make it more explicit (to avoid backward incompatibility issues)
3)
Implicity deactivate all alternatives in defaults which do not deal with the entities in the non-default alt-part. E.g. if an alt statement only treats messages on port p (like the upper tester port), alternatives for ports mapped to the system under test should be inactive for the duration of that alt statement.
Of course, while option 3, in my opinion, would be the most logical solution wich requires the least amount of change by the users and as it is the closest to what people expect when they write an alt statement, it is also the most backward incompatible one (though some of the 'incompability' would probably result in fixing unintended behavior in existing, standardized test suites)
As a compromise between 1 and 3 which is not backward incompatible, the categories given to the alt statement could be the the covered ports/timers/components as a list (normally one) with an additional short-form which results in the semantics of 3 (i.e. active for those entities that are covered by the non-default alternatives).
alt (p, t) { [] p.receive(X) {} [] t.timeout {} }
// no default alternatives for things not happening on p or t
alt (?) { [] p.receive(X) {} [] t.timeout {} }
// same semantics as above
CR7798.docx (192,796) 06-08-2019 14:59http://oldforge.etsi.org/mantis/file_download.php?file_id=3819&type=bug
CR7798-2.docx (366,108) 07-08-2019 12:47http://oldforge.etsi.org/mantis/file_download.php?file_id=3831&type=bug
CR7798-3.docx (296,378) 07-08-2019 13:34http://oldforge.etsi.org/mantis/file_download.php?file_id=3835&type=bug