[asterisk-dev] [Code Review] 3420: Testsuite: Call Files' Max Retries

[opticron]

> On May 1, 2014, 9:06 a.m., opticron wrote:
> > ./asterisk/trunk/tests/pbx/call_file_retries_fail/test-config.yaml, lines 15-17
> > <https://reviewboard.asterisk.org/r/3420/diff/5/?file=57920#file57920line15>
> >
> >     This custom module could be replaced with an AMIEventModule invocation with the following configuration:
> >     
> >     ami-config:
> >         -
> >             type: 'headermatch'
> >             conditions:
> >                 match:
> >                     Event: 'UserEvent'
> >                     Result: 'fail'
> >             count: '4'
> 
> Scott Emidy wrote:
>     This causes the test to pass, but after the reactor has timed out. Is there any way I can get it to see the UserEvents and stop the reactor after it does?
>

The HangupMonitor module seems well-suited for this task.


- opticron


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


On April 25, 2014, 3:28 p.m., Scott Emidy wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3420/
> -----------------------------------------------------------
> 
> (Updated April 25, 2014, 3:28 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23218
>     https://issues.asterisk.org/jira/browse/ASTERISK-23218
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> These tests involved checking that call files max retries are functioning as planned through four tests:
> 
> 1) The first test (call_file_retries_fail) required that the call file originates a local channel to a dialplan extension that will always fail, and checks to make sure that it ran through all of its max retries.
> 
> 2) The second test (call_file_retries_success) involves a call file that originates a local channel that will fail once, but then is answered before it hits its max retries.
> 
> 3) The third test (call_file_retries_alwaysdelete) consists of checking whether or not the call file was deleted from the [astspooldir]'s outgoing folder when the alwaysdelete option is set to 'no'.
> 
> 4) The fourth and final test (call_file_retries_archive) consists of checking whether or not the call file was placed in [astspooldir]'s outgoing_done folder when archive is set to 'yes'.
> 
> 
> Diffs
> -----
> 
>   ./asterisk/trunk/tests/pbx/tests.yaml 4990 
>   ./asterisk/trunk/tests/pbx/call_file_retries_success/test-config.yaml PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_success/retries_success.py PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_success/configs/ast1/extensions.conf PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_fail/test-config.yaml PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_fail/retries_fail.py PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_fail/configs/ast1/extensions.conf PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_archive/test-config.yaml PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_archive/retries_archive.py PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_archive/configs/ast1/extensions.conf PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_alwaysdelete/test-config.yaml PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_alwaysdelete/retries_alwaysdelete.py PRE-CREATION 
>   ./asterisk/trunk/tests/pbx/call_file_retries_alwaysdelete/configs/ast1/extensions.conf PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/3420/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Scott Emidy
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140501/ba541726/attachment.html>