[asterisk-dev] [Code Review] 2661: Give ARI its own test object in the testsuite

[David Lee]

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

Ship it!


Minor nit in the sample config file.


/asterisk/trunk/sample-yaml/ari-config.yaml.sample
<https://reviewboard.asterisk.org/r/2661/#comment18559>

    This is now a lie, right? ari.py still doesn't honor the apps: settings.


- David Lee


On Aug. 22, 2013, 10:58 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2661/
> -----------------------------------------------------------
> 
> (Updated Aug. 22, 2013, 10:58 a.m.)
> 
> 
> Review request for Asterisk Developers and David Lee.
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> Testing ARI is a bit different than testing normal Asterisk tests. Typically, a test in the Asterisk Test Suite uses the following model:
> 
> 1. Create Asterisk Instances
> 2. Wait for instances to fully boot
> 3. Connect AMI
> 4. Wait for AMI connection
> 5. Spawn channels for test
> 
> Most of the test logic occurs in step number 5 - while it's possible to inject logic into the first four steps without writing a new test object, it isn't easy, particularly if what you need to do is defer the execution of one of those four steps until something else happens. In particular, ARI tests need to connect the websocket prior to step 4, as the AMI connection is what typically causes channels to be created in the dialplan and test execution to begin. If the websocket connection doesn't happen before that point, a channel may enter into the Stasis application before the websocket connects and the test will fail.
> 
> This patch gives ARI its own test object so that it can properly connect the websocket prior to the AMI connection. This changes the startup routine to be:
> 
> 1. Create Asterisk Instances
> 2. Wait for instances to fully boot
> 3. Connect ARI
> 4. Wait for ARI connection
> 5. Connection AMI
> 6. Wait for AMI connection
> 7. Spawn channels for test
> 
> It also duplicates what we currently do for starpy for Autobahn's websocket library as well, which is what the ARI test library uses for connecting to Asterisk.
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/lib/python/asterisk/ari.py 4056 
>   /asterisk/trunk/sample-yaml/ari-config.yaml.sample 4056 
>   /asterisk/trunk/tests/rest_api/continue/configs/ast1/extensions.conf 4056 
>   /asterisk/trunk/tests/rest_api/continue/rest_continue.py 4056 
>   /asterisk/trunk/tests/rest_api/continue/test-config.yaml 4056 
> 
> Diff: https://reviewboard.asterisk.org/r/2661/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

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