Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Avoiding all initialization at every test case(Avoiding all initialization at every test case)
Avoiding all initialization at every test case [message #1780366] Sun, 21 January 2018 16:20 Go to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 35
Registered: July 2017
Location: Berlin, Germany

In the TTCN-3 test suites I've written so far, and which I'm compiling+executing with TITAN, all initialization of state between IUT and testcase is performed completely for every test case. While I understand the rationale behind this and agree it is typically not a good idea to leak state between test cases in a test suite, there are for sure scenarios where it is a completely avoidable overhead.

Example (using GSM/3GPP language but given TITAN history I presume people are familiar with it):

* I want to test the Layer3 MM of a MSC., such as LocationUpdate procedure
* For every test case, TITAN brings up M3UA, establishes AS/ASP with the MSC, then brings up the A interface using BSSMAP RESET procedure, to then finally establish a SCCP/BSSAP/DTAP connection and preforming the L3 MM testing.

So I have to bring up all the lower layers for each and every test case, even though my test is only interested in the highest-level protocol. I have separate test suites for the lower-level protocols, and there's no need in doing a poor mans job at re-testing it at every L3 testcase.

So what I'm looking for is some mechanism by which I can keep some TITAN components running throughout the test suite run, started before the first test case and terminated only after the last testcsase. This way the M3UA/SCCP/BSSMAP-Reset could happen once.

Currently, this lower-layer bring-up (which actually involves more interfaces and protocols than in this example) is taking a multitude of the individual test case. So valuable test execution time is wasted with repeated bring-up of those parts that currently are not even bein tested.

Given that this type of problem basically exists in any complex/deep protocol stack, I would be surprised if there wasn't some kind of solution in either the TTCN-3 language or in TITAN.

One ugly hack would be to simply put many individual tests in one testcase. But then U loose valuable granularity in reporting, i.e. I don't see anymore in which of the many steps in one longer testase actually failed, which is not what I want.

Thanks in advance for any assistance.
Re: Avoiding all initialization at every test case [message #1780398 is a reply to message #1780366] Mon, 22 January 2018 07:55 Go to previous message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 708
Registered: January 2015
Senior Member
Hi Harald,

when a test case terminates , the MTC is destroyed , which means that the test suite cannot sustain signaling or communication links from test case to test case. The connected network does not cope well with such a situation, equivalent with the disappearance of a node ( the node simulated in TTCN-3) from the network:
alarms are raised, supervision screams etc. When re-established , the links need to stabilize which slows down test execution; supervision has memory so may isolate links that appear faulty and so on.

You need a separate executable to circumvent the negative effects; in fact we have a whole class of products we call "daemons" exactly for that : to survive termination of a test case.
These daemons implement the lower layer protocols and they are started at the beginning of a test execution and demolished at the end;
The components for the upper layer protocol/protocols are started and terminated as required by the test cases ; when started, the upper layers will connect to the daemon and the link to the SUT is established.

They are, as I mentioned, typically separate executables and they can be conveniently started /stopped in the [EXTERNAL_COMMANDS] section of the config file.

N.B. this behaviour replicates the TRI (TTCN-3 runtime interface) containing the test adapters as described in the standard.

Right now , we have the below dameonic products:


Please take a look and if interested I will check if I can make them open source.

Best regard


  • Attachment: Daemon.png
    (Size: 39.04KB, Downloaded 47 times)
Previous Topic:Some Titan project statistics
Next Topic:Incomplete Behavior Types Support?
Goto Forum:

Current Time: Wed Mar 21 05:31:34 GMT 2018

Powered by FUDForum. Page generated in 0.01864 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software