[asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error

[Ashley Sanders]

> On March 24, 2015, 11:23 a.m., Matt Jordan wrote:
> > ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py, lines 29-34
> > <https://reviewboard.asterisk.org/r/4520/diff/1/?file=72752#file72752line29>
> >
> >     If your constructor doesn't need to do anything, you don't need to define it. You can just let the default Python constructor do its thing.

Since the referenced class was not being used to contain state, it was removed (per the previous suggestion). So, this issue is no longer relevant :)


> On March 24, 2015, 11:23 a.m., Matt Jordan wrote:
> > ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py, lines 104-117
> > <https://reviewboard.asterisk.org/r/4520/diff/1/?file=72752#file72752line104>
> >
> >     While this is good defensive programming, in this case, your test can trust that Asterisk will send you events that match the data model.
> >     
> >     Asterisk, when compiled with --enable-dev-mode (which generally has to be used with running with the testsuite), will assert if a JSON blob it sends out does not match the Swagger specification. Typically, we run Asterisk with DO_CRASH enabled, which will cause Asterisk to core dump on the asserts.
> >     
> >     Beyond that, it may actually be better to throw an exception if the data model is not correct - Asterisk should not be sending events that don't match the Swagger spec (even if someone compiled Asterisk to not assert).
> >     
> >     Doing this also has the benefit of reducing the size of these methods by quite a lot.

I agree with this. If any of these things fail during the test, I want it to blow up in a loud and obnoxious way.


- Ashley


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


On March 22, 2015, 11:34 p.m., Ashley Sanders wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4520/
> -----------------------------------------------------------
> 
> (Updated March 22, 2015, 11:34 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24802
>     https://issues.asterisk.org/jira/browse/ASTERISK-24802
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis).
> 
> This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing.
> 
> This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable:
> 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up.
> 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied.
> 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied.
> 
>  ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/
> 
> 
> Diffs
> -----
> 
>   ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION 
>   ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/4520/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Ashley Sanders
> 
>

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