> On 6. Mar 2018, at 10:59, Neels Hofmeyr <nhofm...@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