[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/observable_object.py, lines 25-29
> > <https://reviewboard.asterisk.org/r/4520/diff/1/?file=72747#file72747line25>
> >
> >     Rather than injecting a name down into the base class, how about having a method on the class that derived classes should override to provide the name?
> >     
> >     This would let you do something like:
> >     
> >     class ObservableObject(object):
> >     
> >         def get_name(self):
> >             return ''
> >     
> >     
> >         def __format__(self, format_spec):
> >             return self.__class__.__name__ + '[' + self.get_name() + ']'
> >     
> >     
> >     class ConcreteObserver(ObservableObject):
> >     
> >         def get_name(self):
> >             return self.__class__.__name__

While this would be cleaner - it's not going to make much sense for the more generalized classes (ari_client, monitor, abstract test_scenario) - which is where the 'name' property actually matters. I would still have to inject the value of name as a ctor parameter to get it to the overridden property in the generalized class.

>From your example above:

class ObservableObject(object):

    def get_name(self):
        return ''

    def __format__(self, format_spec):
        return self.__class__.__name__ + '[' + self.get_name() + ']'


class AriClient(ObservableObject):

    def get_name(self):
        return "Scenario Name"  <== What does this mean in terms of a generalization, though?


class BabsTestScenario(ObservableObject):
    
    def get_name(self):
        return "Babs"  <== This makes a lot of sense for situations like this, though.


As it is, I need to take the most conservative approach when dealing with generalized and specialized types implementing the same base type.

The names, as redundant as it is, are injected all the way through the construction as a means of creating the logs with messages that are easier to decipher when dealing with multiple test cases running concurrently. Name is really just an 'id'. It is incredibly redundant on the concrete instance of TestScenario, that already prints <Name>TestScenario. 

Also, from the example, the value returned by ObservableObject.self.__class__.__name__ (the base type) is equal to ConcreteObserver.self.__class__.__name__ (the derived type). 


- 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/37bb5545/attachment-0001.html>