[asterisk-dev] [Code Review] 3501: testsuite: add tests for ari userevents

[Scott Griepentrog]

> On May 2, 2014, 9:38 a.m., Matt Jordan wrote:
> > /asterisk/trunk/tests/rest_api/applications/userevents/invalid/test-config.yaml, lines 11-19
> > <https://reviewboard.asterisk.org/r/3501/diff/1/?file=58134#file58134line11>
> >
> >     Another way of handling expected request failures would be to expose the allow_errors attribute on the ARI object through the test object controlling it. Your test-object-config could set that, then have the event matcher do its thing.
> >     
> >     That would be potentially useful for a larger number of tests, and would keep the control of the expected response in the test object.

I've reworked the request mechanism to be it's own object with a better way of handling request failures.  However, this could still be improved upon - I still don't have validation on the response json contents for example.


> On May 2, 2014, 9:38 a.m., Matt Jordan wrote:
> > /asterisk/trunk/tests/rest_api/applications/userevents/multi/configs/ast1/extensions.conf, lines 1-6
> > <https://reviewboard.asterisk.org/r/3501/diff/1/?file=58135#file58135line1>
> >
> >     Egads, 25 seconds?
> >     
> >     This should be made to be event driven.

Changed to an echo, which is what it should have been in the first place.


> On May 2, 2014, 9:38 a.m., Matt Jordan wrote:
> > /asterisk/trunk/tests/rest_api/applications/userevents/invalid/configs/ast1/extensions.conf, lines 3-6
> > <https://reviewboard.asterisk.org/r/3501/diff/1/?file=58133#file58133line3>
> >
> >     This could get racey (and forces the test to run for 3 seconds, when it may be done faster)
> >     
> >     I'd instead have this get dropped into an Echo, and have the test itself hangup the channel when done.

Was supposed to do that, I forgot to clean it up.


> On May 2, 2014, 9:38 a.m., Matt Jordan wrote:
> > /asterisk/trunk/tests/rest_api/applications/userevents/channel/test-config.yaml, line 32
> > <https://reviewboard.asterisk.org/r/3501/diff/1/?file=58132#file58132line32>
> >
> >     That sounds ominous. Racing == bad.
> >     
> >     You may want to structure this such that we only get the user event after we've subscribed to the channel. One way of doing that would be spawn the channel into the Stasis application, subscribe to it, then release it to the dialplan that raises the UserEvent.

I thought of setting a variable to replace the dialplan, but that requires having the app in stasis, which I expressly wanted to avoid in order to enforce the test that the user event was received because of the subscription command (in addition to confirming that the output was correct).  I've updated this to do a 3 second delay before issuing the event, which works even with valgrind.


- Scott


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


On May 12, 2014, 3:43 p.m., Scott Griepentrog wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3501/
> -----------------------------------------------------------
> 
> (Updated May 12, 2014, 3:43 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22697
>     https://issues.asterisk.org/jira/browse/ASTERISK-22697
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> Tests added:
> 
> 1) userevents/channel - check that the dialplan app Userevent() generated event produces correct ARI/AMI events
> 
> 2) userevents/multi - check that various forms of the ARI userevent generate correct ARI & AMI events
> 
> 3) userevents/invalid - check that correct result code is returned for invalid input cases
> 
> Changes to ari.py made to add expected: ### return code checking for HTTP requests.
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/tests/rest_api/tests.yaml 5006 
>   /asterisk/trunk/tests/rest_api/events/user/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/user/multi/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/user/multi/configs/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/user/multi/configs/ast1/pjsip.conf PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/user/multi/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/user/invalid/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/user/invalid/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/user/channel/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/user/channel/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/events/tests.yaml PRE-CREATION 
>   /asterisk/trunk/lib/python/asterisk/ari.py 5025 
> 
> Diff: https://reviewboard.asterisk.org/r/3501/diff/
> 
> 
> Testing
> -------
> 
> Tests pass with userevent code.  Also tested with r3496 valgrind support to insure no invalid references.
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

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