views:

97

answers:

2

Unit and integration testing is usually performed as part of a development process, of course. I'm looking for ways to use this methodology in configuration of an existing system, in this case the Asterisk soft PBX.

In the case of Asterisk, the configuration file is as much a programming language as anything else, complete with loops, jumps, conditionals, etc., and can get quite complex. Changes to the configuration often suffers from the same problems as changes to a complex software product - it can be hard to foresee all the effects without tests in place. It's made worse by the fact that the nature of the system is to communicate with external entities, i.e. make phone calls.

I have a few ideas about testing the system using call files (to create specific calls between extensions) while watching the manager interface for generated events. A test could then watch for an expected result, i.e. dialling *99# should result in the Voicemail application getting called.

The flaws are obvious - it doesn't test the actual result, only what the system thinks is the result, and it probably requires some modification of the system under test. It's also really hard to write these tests robustly enough to only trigger on the expected output, especially if the system is in use (i.e. there are other calls in progress).

Is what I want, a testing system for Asterisk, impossible? If not, do you have any ideas about ways to go about this in a reasonable manner? I'm willing to put a fair amount of development time into this and release the result under a friendly license, but I'm unsure about the best way to approach it.

+2  A: 

Well, it depends on what you are testing. There are a lot of ways to handle this sort of thing. My preference is to use Asterisk Call Files bundled with dialplan code. EG: Create a callfile to dial some public number, once it is answered, hop back to the specified dialplan context and perform all of my testing logic (play soundfiles, listen for keypresses, etc.)

I wrote an Asterisk call file library which makes this sort of testing EXTREMELY easy. It has a lot of documentation / examples too, check it out here: http://pycall.org/. That may help you.

Good luck!

b14ck
That's not a bad library. Most of the tests I envision are of the type "user calls this short number, verify that a call is placed to this other number on the trunk line" or "user calls this number, verify that the call is answered, a sound file played, and a database entry created". The side effects are (relatively) easy to verify, the user experience not so much. :/
calmh
In that case, you'll want to use the AMI (Asterisk Manager Interface), as you can get live status events back as to whether or not the call was made successfully, etc. Check out the docs here: http://www.voip-info.org/wiki/view/Asterisk+manager+API
b14ck
A: 

You could create a set of specific scenarios and use Asterisk's MixMonitor command to record these calls. This would enable you to establish a set of sound recordings that were normative for your system for these tests, and use an automated sound file comparison tool (Perhaps something from comparing-sound-files-if-not-completely-identical?) to examine the results. Just an idea.

Dan Carlson
That won't work. There are a lot of variables when dealing with sound on calls. Static, timing, and other issues will make this nearly impossible.
b14ck
I don't have a lot of experience with audio fingerprinting, and have no idea what granularity the comparison would operate with. However, if you're calling from asterisk box to asterisk box on a local network, which is what I imagine you would use for unit testing, I would guess that a lot of the variables you suggest would be closer to constants. That being said, I too, am unsure how effective this type of unit testing would be, just giving suggestions. : - ).
Dan Carlson