[asterisk-dev] [Code Review] bridging tests: call parking timeout (comebacktoorigin = no)

jrose reviewboard at asterisk.org
Tue Jan 29 11:29:29 CST 2013


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

Review request for Asterisk Developers, Mark Michelson, Matt Jordan, and rmudget.


Summary
-------

This tests four elements of comebacktoorigin=no

First, three individual calls are parked. Each parked call is checked for where it ends up in the dialplan to make sure it is as expected as well as the variables we mention being set in the features.conf sample.

Also, the park-dial extension created to call the parker back is checked upon completion of the first parking timeout as well.

Like with the last parking test, a zombie and the parker die at roughly the same time which make CELs hard to deal with due to out of order events being a possibility.  As with that test, I am omitting the CEL module.


Diffs
-----

  /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_no/Executioner.py PRE-CREATION 
  /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_no/configs/ast1/extensions.conf PRE-CREATION 
  /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_no/configs/ast1/features.conf PRE-CREATION 
  /asterisk/trunk/tests/bridge/parkcall_timeout/comebacktoorigin_no/test-config.yaml PRE-CREATION 
  /asterisk/trunk/tests/bridge/parkcall_timeout/tests.yaml PRE-CREATION 
  /asterisk/trunk/tests/bridge/tests.yaml 3617 

Diff: https://reviewboard.asterisk.org/r/2301/diff


Testing
-------

Tested to see if any variance in expectations resulted in failures to the affected areas.  It does.
Tested to see how out of order tests would be handled.  They fail as expected.
Tested to see if variance to the CDRs would produce failures. It does.
Tested to see what would happen if we never received the Dialplan list entry for the parker dial. Causes failure as expected.
Tested to see what would happen if multiple failures occured. They are all logged and a count of all errors is given.


Thanks,

jrose

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130129/25984ba8/attachment.htm>


More information about the asterisk-dev mailing list