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/gerrit-log@lists.osmocom.org/.
Neels Hofmeyr gerrit-no-reply at lists.osmocom.orgPatch Set 4: > Similar to other patches before: Why are we doing this here and not > in TTCN-3, particularly if it's about entire new tests? I've asked > the question before, but you didn't answer and instead keep senidng > the patches. Please at least let me know what the reasons are... Hmm, that must have slipped my attention, sorry about that. For me it is helpful that when there are comments to a patch that there is a -1 or a +1 marking, so that I don't just see the +2, merge and forget to read... The titan tests are great, yet these tests here also have their justification, and I like them because: - Running a test like this is super fast: 'make check' (== just one shortcut key in my vim setup to save files and run them), so I will instantly know when I broke something while developing. No external dependencies needed; all done in practically zero execution time. - A test like this also runs during our address-sanitizer builds; also in gerrit before the commit is merged, rather than after it is merged and someone noticed the pass percentage hidden in a jenkins job might be different from last time. - These tests are completely insensitive to timing. All gettime is faked and there is no concurrent interplay between components: the tests are guaranteed to run identically every time. - I can easily analyse with gdb and step through a situation without concurrent things happening in other processes. - These tests nail down log output: when I change something, I can immediately verify all the logging that is affected in various situations, in a neat diff. I just need to make my change, run 'make update-exp' and see the logging differences in git. I find this very helpful and reassuring, and it provides a compendium of logging sequences to look up. (This is impossible to nail down in the titan tests due to subtle timing differences in each run.) - I can adjust these tests along with changes to code in a neat series of commits, so I can clearly show how specific fixes change the MSC's behavior, in the git history for later reference. - Here, I pasted hex streams from pcaps exactly as I saw phones and BTSes sending them in, instead of composing them from the titan protocol definitions -- which are great tools without question, but here is also room for testing raw data. So the disadvantages these tests have compared to the titan tests are also advantages in another sense. I would like to cultivate both ways. That said, I'm not actively planning to do very much here anymore besides revisiting and complementing things that are already here, like the LU/CM-Service/Paging and auth+ciph dances. I'm in the meantime expanding the titan tests coverage as well; so far it is taking me far longer to find my way around there, and running them means a lot more commands typed and more waiting for things to get going. So I hope it's ok to also use this test suite as a tool, and not abandon it just because ttcn3 came up. -- To view, visit https://gerrit.osmocom.org/7190 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia1bc57b3dc1f3c3c654ba2d907b16ba925cd03e8 Gerrit-PatchSet: 4 Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-HasComments: No