> 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
>
>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
