Change in osmo-msc[master]: Add tests for transaction routines

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/.

Vadim Yanitskiy gerrit-no-reply at lists.osmocom.org
Mon Jan 14 23:42:41 UTC 2019


Vadim Yanitskiy has posted comments on this change. ( https://gerrit.osmocom.org/12556 )

Change subject: Add tests for transaction routines
......................................................................


Patch Set 9: Code-Review-1

(13 comments)

https://gerrit.osmocom.org/#/c/12556/9/tests/trans/Makefile.am
File tests/trans/Makefile.am:

https://gerrit.osmocom.org/#/c/12556/9/tests/trans/Makefile.am@4
PS9, Line 4: -I$(top_srcdir)/src/libmsc
Looks useless to me. The only header in there is smpp_smsc.h (which should be also moved to 'include' in some separate patch).


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c
File tests/trans/trans_test.c:

https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@34
PS9, Line 34: ref_id
This name looks a bit confusing. What is the meaning of 'ref_id'?
Reference ID? What is the reference then?

As far as I can see, you're always passing transaction ID, so let's name it 'trans_id' then?


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@51
PS9, Line 51: trans_assign_trans_id
You're always calling it with ti_flag = 0. I would really like this test case to cover both '0'B and '1'B cases.


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@68
PS9, Line 68: base_callref
What is the point of passing callref?
Why not to use a static counter?


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@79
PS9, Line 79: return
I would rather use OSMO_ASSERT here.


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@83
PS9, Line 83: return
... and here.


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@88
PS9, Line 88: return
Let's just imagine that trans_has_conn() returns X != 0. This test would just fail, and one would have to investigate *why*, most likely by adding debug printf()s or asserts.

This is why I also recommend to use OSMO_ASSERT here too.


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@92
PS9, Line 92: return
... and here.


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@94
PS9, Line 94: vlr_subscr_name
You say 'connection', but print subscriber name? o_O


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@134
PS9, Line 134: base_callref
Hmm, allocating multiple transactions with same callref?

It's a known issue (at least to me), that trans_alloc() would happily allocate a transaction with duplicate callref. And I expected that this test case would disclose this problem...


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.c@151
PS9, Line 151: \n\tCleared   %u transactions.
Let's split up this message into 2 printf() calls.


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.err
File tests/trans/trans_test.err:

https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.err@1
PS9, Line 1: Unknown RAN type
Cosmetic: you could use any 'known' RAN type to avoid this.


https://gerrit.osmocom.org/#/c/12556/9/tests/trans/trans_test.err@2
PS9, Line 2: 
Also, I expected to see debug messages here, like:

  (ti %02x sub %s callref %x) New transaction

transaction.c (for some reason) is using DCC, so
you could set its level to DEBUG.



-- 
To view, visit https://gerrit.osmocom.org/12556
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I78dfb7cd35073a305cf668beda7d9d58d5a5a713
Gerrit-Change-Number: 12556
Gerrit-PatchSet: 9
Gerrit-Owner: Max <msuraev at sysmocom.de>
Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Max <msuraev at sysmocom.de>
Gerrit-Reviewer: Vadim Yanitskiy <axilirator at gmail.com>
Gerrit-Comment-Date: Mon, 14 Jan 2019 23:42:41 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: Yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190114/10566108/attachment.htm>


More information about the gerrit-log mailing list