[asterisk-dev] [Code Review] 2498: Test Suite: Pluggable CEL verification module

[opticron]

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



/asterisk/trunk/lib/python/asterisk/ami.py
<https://reviewboard.asterisk.org/r/2498/#comment16862>

    It seems that all the Exceptions raised in your additions are related to misconfigurations.  The associated error messages should provide the config section being parsed as a string to assist in development of tests.



/asterisk/trunk/lib/python/asterisk/ami.py
<https://reviewboard.asterisk.org/r/2498/#comment16863>

    This error message looks incorrect.



/asterisk/trunk/lib/python/asterisk/ami.py
<https://reviewboard.asterisk.org/r/2498/#comment16864>

    Idem.



/asterisk/trunk/sample-yaml/ami-config.yaml.sample
<https://reviewboard.asterisk.org/r/2498/#comment16867>

    If "cel" is the one and only key in this list entry and MUST exist, does it need to be there at all? i.e. Just have the "id", "match", and "partialorder" keys directly under the "-".


- opticron


On May 14, 2013, 3:30 p.m., jbigelow wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2498/
> -----------------------------------------------------------
> 
> (Updated May 14, 2013, 3:30 p.m.)
> 
> 
> Review request for Asterisk Developers and Matt Jordan.
> 
> 
> Bugs: ASTERISK-21422
>     https://issues.asterisk.org/jira/browse/ASTERISK-21422
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> This uses AMI to allow verification of CEL messages. It is based on the AMIOrderedHEaderMatchInstance but differs in that it's specifically for checking CEL messages and that a partial order may be specified to allow messages to be out of order.
> 
> A condition match item of "Event: CEL" is always used and can not be overridden however additional condition match items may be specified. The list of requirements are checked in the order listed unless the optional 'partialorder' is specified.
> 
> Best explained by the description in the sample yaml file:
> 
> * If the event does successfully meet the 'match' critera of the
>   requirement expected and...
>   * a 'partialorder' is not specified, then this requirement
>     passes. Therefore the second requirement in the
>     requirements list is then expected.
>   * a 'partialorder' is specified and...
>      * the criteria is also met, then the requirement
>        passes. Therefore the second requirement in the
>         requirements list is then expected.
>      * the criteria is not met, the test is failed.
> * If it does not meet the 'match' criteria of the requirement
>    expected and...
>    * a partial order is not specified, the test is failed.
>    * a partial order is specified, it will remember the
>      requirement it is on and check if the 'match' criteria of
>      the next requirement in the list is met. It will continue
>      with each requirement in the order listed (where all the
>      criteria hasn't previously been met) until the 'match'
>      criteria is met or the end of the requirements list has
>      been reached at which point the test is failed.
>       * If the 'match' critera is successfully met and a...
>          * partial order is not specified, the test is
>            failed as the event arrived to early.
>          * partial order is specified and it's criteria
>            is not met, the test is failed.
>          * partial order is specified and it's criteria
>            is met, it is considered a successful match. It will
>            then move on and expect the next requirement in the
>            list from the point of the remembered requirement.
> 
> Note: If the 'match' criteria is met but not the 'partialorder' criteria of a requirement, the test is failed instead of checking other listed requirements. I did not run into a scenario where this prevented a test from properly failing or passing during my testing. It appears it would be very uncommon to run into this. 
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/configs/cel.conf 3777 
>   /asterisk/trunk/lib/python/asterisk/ami.py 3777 
>   /asterisk/trunk/sample-yaml/ami-config.yaml.sample 3777 
> 
> Diff: https://reviewboard.asterisk.org/r/2498/diff/
> 
> 
> Testing
> -------
> 
> * Tested by creating a simple test that used the SimpleTestCase test object to create a local channel and execute some dialplan. This created an environment where the CEL events would not always be in the same order upon each execution. Specifying a partial order on some of the requirements allowed to successfully work around the CEL events not being in the same order thus allowing the test to pass. Used it to also ensure expected failures did in fact cause the test to fail.
> * Tested by modifying the bridge/bindxfer_nominal/ test (which actually performs a blind transfer) to use this and again was able to use the partialorder on some of the requirements to work around the CEL events not always being in the same order.
> * Also tested doing the same with the bridge/blindxfer_setup/ test
> * Tested to ensure that only those EventName's listed in the requirements are checked and those not are ignored.
> 
> 
> Thanks,
> 
> jbigelow
> 
>

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