|Age||Commit message (Collapse)||Author||Files||Lines|
It would be nicer to select the network programs as scenarios, i.e.
independently from the specifics of tests that don't care whether a NITB or a
MSC+BSC is in place. See OS#2270.
For now have a separate script for BSC+MSC+HLR operation to be able to rapidly
get the binaries to work. We might even simply drop the NITB style, in which
case we don't need to make it configurable.
I would like to use the IP addresses also for OsmoBSC processes, so it is more
than clear now that 'nitb_iface' was the wrong naming choice.
The only distinction we may need in the future is public versus loopback
interface. To add that, we may add a trait to the 'ip_address' resource
- addr: 10.42.42.1
- addr: 127.0.0.1
This way we can substitute public vs loopback addresses flexibly (e.g. using
* Add Junit output file support
* Differentiate between an expected failure test and an error in the
test, as described in JUnit.
* In case of an error/exception during test, record and attach it to the
Test object and continue running the tests, and show it at the end
during the trial report.
/suites will be the definitive GSM tests collection where everyone should contribute.
Since we're using /example on our current osmo-gsm-tester setup actually as-is,
change paths.conf to point at ../suites.