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/.
Harald Welte laforge at gnumonks.orgHi Keith,
On Fri, May 24, 2019 at 02:41:39PM +0200, Keith wrote:
> Given that ttcn3 is still a new language to me,
> this represents something of a learning curve, of course.
I underestand and appreciate that. IT was new to all of us some ~2.5 years ago.
The advantage *now* is that we pretty much have the infrastructure in
place for most of the things we'd typically encounter in testing (with
exception of the PCU), and plenty of examples (the existing test cases).
This should hopefully make writing new tests a lesser challenge. From a
syntactical point of view, it's luckily not so far from C. And for sure
one can simply hack at it without understanding the full language and/or
all of its concepts.
Eric is currently going thorugh this, and just got his first new test
(about initial TA in channel activation) merged.
> I know that there is a docker setup (I haven't played with it yet) -
> I'm just wondering if there is a easier (better) way than each
> individual developer running there own entire ttcn3/osmo stack test
> environment?
For executing the test suite, the dockerized setup is clearly the lowest
entrance barrier. It requires virtually zero configuration (aside from
docker being around) - but building the images, etc. of course takes
time - and we don't use ccache in that setup, so build times are long.
I wuold assume that in order to have quick development cycles and to
control various things interactively one would normally want to run the
testsuite natively while developing tests. There's a bit of hassle
involved in that, in order to get the adresses/ports/etc. all configured
in a way to work. But that should be one-time exercise...
We can have jenkins jobs to execute newly developed tests from personal
branches on build hosts, if you think that would make it simpler. But
honestly, I think one wants to see the test running locally, quickly
edit a line, restart, ...
> Maybe I'm over estimating the complexity of that?
executing the tests shouldn't be the complex part - at least not more
complex than setting up a cellular network with elements of different
suppliers, where all kinds of addresses, parameters, etc. have to be
set up (i.e. not having all the 'atomagic' Osmocom stuff we introduced
to simplify nitb-like setups, with automatic routing key management, ...)
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)