[asterisk-dev] [Code Review]: Add unit tests for jitterbuf.c

[Mark Michelson]

> On March 13, 2012, 5:22 p.m., Mark Michelson wrote:
> > The test documentation should be altered to make sure to explicitly state that only the adaptive jitterbuffer is tested.
> > 
> > With the exception of the resynch test, the voice and control versions of each test are exactly the same, just with a different frame type specified for jb_put(). The common code can be factored out into functions that take the test name and type of frame to place in the jitterbuffer. This will greatly reduce the size of this file.
> 
> Matt Jordan wrote:
>     I do think the test documentation should be clearer about what is being tested - main/jitterbuf.c (so I'll probably rename this to test_jitterbuf, etc.)
>     
>     This is *not* a unit test for the adaptive jitter buffer or that abstract jitter buffer API.
>     
>     The fact that the adaptive jitter buffer happens to currently use jitterbuf.c as its implementation is a detail that is abstracted away.  That implementation could be changed, and as long as the abstract API doesn't change, it shouldn't effect a unit test written to exercise that code (or at least, that's the theory).  In this particular case, these unit tests are concerned with the handling of JB_TYPE_CONTROL frames by jitterbuf.c, as a code change to that handling is what prompted the writing of these unit tests.  The abstract API and the adaptive jitter buffer do not use those frames - so if this was a unit test for the abstract API / adaptive jitter buffer, there'd be no way to exercise that functionality.  On top of that, the unit tests don't even attempt to access the adaptive jitter buffer through the abstract API - so there's no way you could say that this actually tests the adaptive jitter buffer.
>     
>     I'll refactor some of the portions of the tests - some of the reading of the frames as well can probably be refactored out.  Given that each test 'pair' requires its own particular insertion function, the SLOC may not be reduced by as much as it might appear, although it would help if we ever decided to test any of jitterbuf.c's frame types.
>

Sure, when I said "adaptive jitterbuffer" I meant the jitterbuffer implementation in main/jitterbuf.c. I tend to think of that jitterbuffer as the adaptive one, and the one in main/fixedjitterbuf.c as the fixed one. Specifying that this tests main/jitterbuf.c will satisfy what I was driving at in my comment while also being more technically accurate.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1815/#review5800
-----------------------------------------------------------


On March 14, 2012, 9:22 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1815/
> -----------------------------------------------------------
> 
> (Updated March 14, 2012, 9:22 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch adds unit tests to cover major functions in jitterbuf.c.  This include jb_put, jb_get, jb_next, as well as general information and statistic gathering.  The scenarios include:
> 
> 1) Nominal - adding voice/control frames and making sure that all added frames are removed and in the correct time slots
> 2) Out of Order - some voice/control frames arrive out of order with respect to the previous frame.  The tests check that when reading from the jitter buffer, the frames are reordered
> 3) Lost - some voice/control frames never arrive.  In the case of voice, the jitter buffer should interpolate the frame; in the case of control, the jitter buffer should report that no frame exists at that time slot
> 4) Late - the arrival time of some voice/control frames does not occur at the same rate as surrounding frames
> 5) Resync - test that voice/control frames that break the resync threshold trigger a resync of the jitter buffer
> 6) Overflow - test that adding voice/control frames that exceed the maximum time length of the buffer are dropped
> 
> This change was prompted by https://reviewboard.asterisk.org/r/1814 - not all tests will pass without that patch.  
> 
> 
> This addresses bug ASTERISK-18964.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18964
> 
> 
> Diffs
> -----
> 
>   /trunk/tests/test_jitterbuf.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/1815/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120314/c3519b22/attachment-0001.htm>