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

[Mark Michelson]

> On Aug. 9, 2013, 8:12 p.m., David Lee wrote:
> > /asterisk/trunk/tests/rest_api/continue/test-config.yaml, lines 23-25
> > <https://reviewboard.asterisk.org/r/2661/diff/2/?file=43765#file43765line23>
> >
> >     So this specifies that the test should use the app 'continue-test' to connect to the WebSocket, but everything else is using the app 'testsuite'.
> >     
> >     I'm thinking that the apps ari-config isn't working, and it's just going with the default.
> 
> Matt Jordan wrote:
>     It appears that way.
>     
>     Currently, the test_object is attempting to read that out, which is incorrect. The test object isn't what verifies the events coming back from the websocket.

Shouldn't "apps: continue-test" be in the test-object-config section either instead of or in addition to the ari-config section?


- Mark


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


On Aug. 3, 2013, 2:49 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2661/
> -----------------------------------------------------------
> 
> (Updated Aug. 3, 2013, 2:49 p.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/sample-yaml/ari-config.yaml.sample 3975 
>   /asterisk/trunk/lib/python/asterisk/ari.py 3975 
>   /asterisk/trunk/addons/Makefile 3975 
>   /asterisk/trunk/tests/rest_api/continue/configs/ast1/ari.conf PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/continue/configs/ast1/extensions.conf 3975 
>   /asterisk/trunk/tests/rest_api/continue/rest_continue.py 3975 
>   /asterisk/trunk/tests/rest_api/continue/test-config.yaml 3975 
> 
> 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/20130819/e1c7e709/attachment.htm>