GSM tester scenarios and beyond

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Holger Freyther holger at freyther.de
Tue Mar 6 17:25:13 UTC 2018



> On 6. Mar 2018, at 10:59, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 


> The only benefit here is that a number of test cases don't each setup and
> tear down the core net, so they would be a bit faster. And there's also
> the drawback of complexity about handling situations where one test
> manages to crash a program which then affects subsequent tests -- but I
> guess I would just let all remaining tests fail then.

For optimization the state of CRIU might be good enough. Once a network
is up you might be able to take a snapshot (and resume it). But we probably
don't have this problem yet.



> So I guess all I would implement would be some convenience function that
> allows reducing code dup across the test functions, for tests that just
> want a working network with the modems subscribed, ready for testing.

Makes sense to solve it like this. I haven't looked at TTCN-3 test
composition but I do like the Phexample[1] approach. In one test one
can use the result of other tests. E.g. something like this:

smpp = suite.given_a_configured_network().smpp_interface()
smpp.submit_sm...


Anyway... Talk is cheap. Given that a scenario is the merged config, would
you take changes to accept the rename (scenario->config)?


	holger





[1] http://smalltalkthoughts.blogspot.hk/2009/11/phexample-because-examples-expand-on.html


More information about the OpenBSC mailing list