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

[jbigelow]

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

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/20130507/4f170bdb/attachment.htm>