Lately, you may have seen some submissions from Sangoma’s CommUnity team (covered in it’s own post.)  Many of these submissions were small but helpful changes, but even these small changes in behavior require matching Testsuite submissions.  We are going to look at two of these today – each for a different reason.

ASTERISK-30405

The first is notable because we were able to create a very simple test for a cli change using only local channels.  ASTERISK-30405 was submitted to cover a change in the Directory dialplan application to skip dialing the selected extension and instead set it as a new variable DIRECTORY_EXTEN.

For this test we include the AppTest module, one of the standard pluggable modules to create a local channel connected to the directory:

test-modules:
   test-object:
      config-section: test-object-config
      typename: 'apptest.AppTest'

test-object-config:
   app: 'Directory'
   scenarios:
      -
         channels:
            -
               channel-id: 'selectchan'
               channel-name: 'LOCAL/select@directory'
               context: 'default'
               exten: 'wait'
               start-on-create: True

The corresponding dialplan generates a UserEvent before entering the Directory (note that we are setting the ‘s’ option which triggers the new feature):

[directory]
exten => select,1,NoOp()
   same => n,Answer()
   same => n,UserEvent(DirectoryEnter)
   same => n,Directory(,,s)

exten => h,1,NoOp()
   same => n,UserEvent(ExtensionSelect,Status: ${DIRECTORY_EXTEN})
   same => n,Hangup()

The DirectoryEnter UserEvent that tells us it’s time to go ahead and select our extension ‘dog’:

events:
   -
      type: 'headermatch'
      conditions:
         match:
            Event: 'UserEvent'
            UserEvent: 'DirectoryEnter'
            Channel: 'Local/select@directory-.*'
      actions:
         # select user 'dog'
         -
            action-type: 'send-dtmf'
            delay: '1'
            dtmf: '364'
         # choose to direct to selected user
         -
            action-type: 'send-dtmf'
            delay: '4'
            dtmf: '1'
         -
            action-type: 'set-expected-result'
            expected-result: 'Send DTMF'

Our dialplan above contains a hangup handler which we use to generate a UserEvent of ExtensionSelect with the status set to whatever Application_Directory set in DIRECTORY_EXTEN.  If the expected value of ‘2020’ (dog’s extension) is returned, the test passes.  If anything else, the test fails.

   -
      type: 'headermatch'
      conditions:
         match:
            Event: 'UserEvent'
            UserEvent: 'ExtensionSelect'
            Status: '2020'
      actions:
         -
            action-type: 'set-expected-result'
            expected-result: 'Success'

ASTERISK-30446

The second test is a different story, even though the feature itself isn’t too much more complicated.  Notable for the opposite reason, it is an outlier in that it required a test event be added to Asterisk.  ASTERISK-30446 is a submission to add an optional periodic beep to call monitoring initiated be feature code.  This is enabled via touch variable, which is simple enough to set in the dialplan.

The test itself is fairly unremarkable.  We use a few lines of dial plan to create two extensions, a ‘beep’ and a ‘nobeep’.  The dialplan for the ‘beep’ scenario has the touch variable set and the ‘nobeep’ does not.  We use sipp to dial in to each extension.  Simple enough.

Only issue is, how do we detect that the beep did or did not occur?  In this case we do so by adding a test suite event to the periodic hook that corresponds to the beep:

ast_test_suite_event_notify("PERIODIC_HOOK_ENABLED", "Exten: %s\r\nChannel: %s\r\nInterval: %u\r\n", args.exten, ast_channel_name(chan), interval);

We can then look for this event in our test-config.yaml:

ami-config:
     -
          ami-events:
               conditions:
                    match:
                         Event: 'TestEvent'
                         Channel: 'Local/waiter@waitstaff-*'
                         state: 'PERIODIC_HOOK_ENABLED'
               count: 1

So here we have two tests, both simple but both unique.  One borrows an existing custom module and one required a new test event for Asterisk, but both tests are simple in concept and in execution.  Hopefully they shed some light on how working with the existing Asterisk Testsuite framework can lead to simple solutions with a little creativity.