[Asterisk-code-review] tests/remote-test: Add a sample remote test (testsuite[master])

[Matt Jordan]

Matt Jordan has posted comments on this change.

Change subject: tests/remote-test: Add a sample remote test
......................................................................


Patch Set 2:

> > > I think that somewhere in the test-config.yaml file, there
 > needs
 > > to
 > > > be some sort of indication of what is expected to exist on the
 > > > remote Asterisk instance to enable the test to execute.
 > > >
 > > > For instance, in this test, it is expected that there is a
 > > default
 > > > context with an s extension in it, and app_echo is expected to
 > be
 > > > loaded.
 > > >
 > > > For a small example like this, one can deduce what's expected
 > to
 > > be
 > > > there simply from the description, but I think setting a
 > > precedent
 > > > of spelling out the expected content on the remote Asterisk
 > will
 > > > make it easier for people to know what to expect.
 > > >
 > > > I would hope that eventually it would be expected to push
 > > expected
 > > > configuration for individual tests to the remote Asterisk so
 > > there
 > > > is no assumption of what is on the remote Asterisk when the
 > test
 > > > runs. This would also allow for tests to be able to push their
 > > own
 > > > configuration that would otherwise conflict with each other.
 > > >
 > > > For the time being, push configuration to remote Asterisks is a
 > > > ways off, but I think that noting the expectations for the
 > remote
 > > > Asterisk can be done for the time being.
 > >
 > > Do you think the description should just be updated, or are you
 > > envisioning some other fields in the YAML that describe the
 > > expected configuration of the remote system?
 > >
 > > And yes, push configuration to remote systems is a different task
 > > than this one. For example, one could write a pluggable module
 > that
 > > used AMI to dynamically construct a dialplan - but that'd make
 > > these reviews a big larger :-)
 > 
 > I'm picturing this as the first of a multi-phase process. So you
 > could approach it from either of the ways you suggested. The upside
 > to having something specified in yaml is that code could eventually
 > be written to take that yaml and push the appropriate
 > configuration. If you just describe the expected configuration in
 > prose, then eventually, once push configuration code has been
 > written, you would have to retrofit all of the existing remote
 > tests with the formal yaml later.

Since I'm not doing anything with the channel driver configuration, I'll punt on a draft spec for that.

For dialplan, how about something like:

dialplan:
  default:
    s:
      - Answer()
      - Hangup()

This follows a model of a dictionary of contexts, each containing a dictionary of extensions, each containing a list of instructions to execute.

Generally, we should be able to infer the priority from the position within the ordered list of an extension. The only exception to this model would be hints and labels. Both could be handled by changing the type of the entry in the list entry from a basic string to a dictionary, and parsing out the entries in that case:
   - {'type': 'hint', 'entry': 'PJSIP/foo' }
   - Answer()
   - {'label': 'teapot', 'entry': 'Hangup()' }

Or something like that.

-- 
To view, visit https://gerrit.asterisk.org/1522
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I857c5f20d4c260be73697062506f63cb3533c3a8
Gerrit-PatchSet: 2
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Matt Jordan <mjordan at digium.com>
Gerrit-Reviewer: Anonymous Coward #1000019
Gerrit-Reviewer: Mark Michelson <mmichelson at digium.com>
Gerrit-Reviewer: Matt Jordan <mjordan at digium.com>
Gerrit-HasComments: No