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

[jbigelow]

> On May 8, 2013, 11:05 a.m., Matt Jordan wrote:
> > /asterisk/trunk/sample-yaml/ami-config.yaml.sample, lines 143-151
> > <https://reviewboard.asterisk.org/r/2498/diff/1/?file=37340#file37340line143>
> >
> >     I think having the identifiers be implicit and numeric will make this difficult, particularly when we start to get into having CEL checks with a few dozen requirements/matches.
> >     
> >     I'd have each requirement have an ID that can be a string. That way, you can have things like:
> >     
> >      after: 'sip_foo_created'
> >      before: 'sip_foo_hungup'

I had a feeling this would be brought up.  :)


> On May 8, 2013, 11:05 a.m., Matt Jordan wrote:
> > /asterisk/trunk/lib/python/asterisk/ami.py, lines 288-292
> > <https://reviewboard.asterisk.org/r/2498/diff/1/?file=37339#file37339line288>
> >
> >     Holy long debug statement. I'd shorten that up to something like:
> >     
> >     LOGGER.debug('No expected header for %s: using ^$')
> >

Ha, yes it is. That's what happens when I turn comments into log messages.


- jbigelow


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


On May 7, 2013, 1:29 p.m., jbigelow wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2498/
> -----------------------------------------------------------
> 
> (Updated May 7, 2013, 1:29 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/lib/python/asterisk/ami.py 3764 
>   /asterisk/trunk/configs/cel.conf 3764 
>   /asterisk/trunk/sample-yaml/ami-config.yaml.sample 3764 
> 
> 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/20130509/37f3b31d/attachment-0001.htm>