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/osmocom-net-gprs@lists.osmocom.org/.
Holger Hans Peter Freyther hfreyther at sysmocom.deOn Tue, Jul 24, 2012 at 03:42:33PM +0200, jolly wrote: > Good evening, > > i think it is quite complex to do tests. the scheduler does not deal > with any class. it just assigns up and downlink ressource to blocks of a > specific timeslot, if it is assigned to TBFs. in order to test all > classes, we need to check the multislot algorithm. in my opinion, the > only way to test all this would be to emulate a phone with all different > classes, do up and downlink assignment, and check if the assigned slots > comply to the classes. well, your knowledge about the code and the GPRS specification is greater than mine. It is a hard requirement to be able to test this code and I can give you general advice how to structure your code to make this possible. The complexity to test really boils down to how the code is structured, I agree that with the given structure (long functions, concerns mixed) it is difficult to test but given the tbf.txt file some great unit tests are described and just need to be implemented in C. Some very short basics. A unittest tests a part (an unit, a module, an algorithm) of the whole system in isolation. In general there are white and black box tests, with white one actually knows the implementation and aims for full coverage (e.g. every possible combination, sqlite is a project doing that). When a method is called there will be a return value and a side-effect (e.g. the state of TBF is changed) both can and should be observed when writing a test. One example of making code testable: The gprs_rlcmac_rcv_rts_block method can be split into several units that can be tested separately. This can be done for many other methods as well: 1.) sched_poll(poll_fn, out **poll_tbf, out *ul_ack_tbf...) (maybe return a struct with pointers to the queues) 2.) int (usf) sched_select_uplink(in *pdch) the next_ul_tfi side-effect might not be in that method 4.) sched_select_ctrl_msg(in *queues) 3.) msgb* sched_select_downlink(in *pdch) 5.) the rest of the method into a new method that generates the msgb.. I understand that it might be difficult to find a structure that makes testing more easy but in most cases it exists. holger -- - Holger Freyther <hfreyther at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte