Automatic Testing in Osmocom
So far, in many Osmocom projects we have unit tests next to the code.
Those unit tests are executing test on a per-C-function basis, and
typically use the respective function directly from a small test
program, executed at
make check time. The actual main program (like
OsmoBSC or OsmoBTS) is not executed at that time.
We also have VTY testing, which specifically tests that the VTY has proper documentation for all nodes of all commands.
Then there's a big gap, and we have osmo-gsm-tester for testing a full cellular network end-to-end. It includes physical GSM modesm, coaxial distribution network, attenuators, splitter/combiners, real BTS hardware and logic to run the full network, from OsmoBTS to the core - both for OsmoNITB and OsmoMSC+OsmoHLR based networks.
However, I think a lot of testing falls somewhere in between, where you want to run the program-under-test (e.g. OsmoBSC), but you don't want to run the MS, BTS and MSC that normally surroudns it. You want to test it by emulating the BTS on the Abis sid and the MSC on the A side, and just test Abis and A interface transactions.
For this kind of testing, I have recently started to investigate available options and tools.
Several months ago, during the development of OsmoSTP, I disovered that the Network Programming Lab of Münster University of Applied Sciences led by Michael Tuexen had released implementations of the ETSI test suite for the M3UA and SUA members of the SIGTRAN protocol family.
The somewhat difficult part is that they are implemented in scheme, using the guile interpreter/compiler, as well as a C-language based execution wrapper, which then is again called by another guile wrapper script.
I've reimplemented the test executor in python and added JUnitXML output to it. This means it can feed the test results directly into Jenkins.
I've also cleaned up the Dockerfiles and related image generation for
sua-test images, as well
as some scripts to actually execute them on one of the Builders. You
can find related Dockerfiles as well as associtaed Makfiles in
Triggering the builds is currently periodic once per night, but we could of course also trigger them automatically at some later point.
For OpenGGSN, during the development of IPv6 PDP context support, I wrote some test infrastructure and test cases in TTCN-3. Those test cases can be found at http://git.osmocom.org/osmo-ttcn3-hacks/tree/ggsn_tests
I've also packaged the GGSN and the test cases each into separate Docker
Dockerfiles and Makefiles can again be found in
http://git.osmocom.org/docker-playground - together with a Eclipse
TITAN Docker base image using Debian Stretch called
Using those TTCN-3 test cases with the TITAN JUnitXML logger plugin we can again integrate the results directly into Jenkins, whose results you can see at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test/14/testReport/(root)/GGSN_Tests/
I've built some infrastructure for Gb (NS/BSSGP), VirtualUm and other testing, but yet have to build Docker images and related jenkins integration for it. Stay tuned about that. Also, lots more actual tests cases are required. I'm very much looking forward to any contributions.