ttcn3
/
osmo-ttcn3-hacks
mirror of https://gerrit.osmocom.org/osmo-ttcn3-hacks
10
0
Fork 1
Code Issues Releases Wiki Activity

bsc: allow individual T_guard timeout via f_init() 

The TC_ho_neighbor_config_* tests sometimes take longer than 30 seconds,
because they run multiple handovers. Since they don't have access to the
Test_CT, they cannot restart the T_guard. The simplest solution is to choose a
longer T_guard timeout for those tests specifically, by adding an argument to
f_init(). (A longer timeout for those tests is following in another patch.)

Why f_init()? Assigning a different default value to T_guard seems to not be
possible, but a different timeout value can be passed to T_guard.start(), which
happens in f_init().

Change-Id: I14918f6a44d6fa1bd5c3e133757ebdbe32813b33
This commit is contained in:
Neels Hofmeyr 2020-06-16 00:30:47 +02:00
parent 0fbec5678d
commit 4fbad7fc1a
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
bsc/BSC_Tests.ttcn
View File

@ -104,7 +104,7 @@ type component test_CT extends CTRL_Adapter_CT {
/*Configure T(tiar) over VTY, seconds */
var integer g_bsc_sccp_timer_iar := 15 * 60;
/* global test case guard timer */
/* global test case guard timer (actual timeout value is set in f_init()) */
timer T_guard := 30.0;
}
@ -384,7 +384,7 @@ private function f_logp(charstring log_msg) runs on MSC_ConnHdlr
* \param nr_msc Number of virtual MSCs to bring up to connect to osmo-bsc.
*/
function f_init(integer nr_bts := NUM_BTS, boolean handler_mode := false, boolean allow_osmux := false,
integer nr_msc := 1) runs on test_CT {
integer nr_msc := 1, float guard_timeout := 30.0) runs on test_CT {
var integer bssap_idx;
var integer i;
@ -393,7 +393,7 @@ function f_init(integer nr_bts := NUM_BTS, boolean handler_mode := false, boolea
}
g_initialized := true;
T_guard.start;
T_guard.start(guard_timeout);
activate(as_Tguard());
f_init_vty("VirtMSC");