[asterisk-dev] Question on the SIPPTest class in the testsuite

[Paul Belanger]

On 12-10-04 11:21 AM, nitesh bansal wrote:
> Hello Matthew,
>
> I am not sure if you understoood my problem. I would like to explain it
> again and hopefully it will clear up any confusion if there is any;
>
> "This is a kind of race condition. I understand that SIPPTest launches the
> SIPP scenarios as soon as it detects that Asterisk has started. But after
> asterisk is started, it takes some time to load all the
> modules. I believe that SIPPTest should wait for asterisk to fully load all
> the modules before it spawns the SIPP scenarios, because i don't see any
> point in initiating a call with asterisk if asterisk has not
> yet loaded the dialplan. "
>
> Awaiting your feedback.
>
> Regards,
> Nitesh Bansal
>
>
>
> On Thu, Oct 4, 2012 at 3:33 PM, Matthew Jordan <mjordan at digium.com> wrote:
>
>> On 10/04/2012 04:37 AM, nitesh bansal wrote:
>>> Hello All,
>>>
>>> I am using SIPPTest class to write my own test cases in the asterisk
>>> testsuite. In most of the cases, run-test looks as follows
>>>
>>> <<<<<<
>>>
>>> SIPP_SCENARIOS = [
>>>      {'scenario' : 'uas.xml',},
>>>      {'scenario' : 'uac.xml',},
>>>
>>> ]
>>>
>>>
>>> def main():
>>>      test = SIPpTest(WORKING_DIR, TEST_DIR, SIPP_SCENARIOS)
>>>      reactor.run()
>>>      if not test.passed:
>>>          return 1
>>>
>>>      return 0
>>>
>>>>>>>>>
>>>
>>> All of my cases need Asterisk to go to the diaplan, but i have observed
>>> that somtimes, my SIPP test cases start running before asterisk has even
>>> loaded the dialplan, which causes testcas to fail.
>>>
>>> Is there any work around for this situation.
>>
>> The SIPpTest class automatically starts the SIPp scenarios when it
>> detects Asterisk has started.  This works well when you have SIPp
>> scenarios acting as a UAC that do not need to wait on a condition in
>> Asterisk to start.  Many SIP scenarios fall into that category.  The
>> SIPpTest class was written to accommodate those scenarios specifically.
>>
>> If, however, you have a scenario where you need to initiate something in
>> Asterisk prior to starting the SIPp scenario, then the SIPpTest class is
>> probably not appropriate.  In that case, you may want to write a test
>> that utilizes a SIPp scenario in the framework of a "regular" TestCase
>> derived test.  You can use one of the following:
>>
>> * SIPpScenario - manages a single SIPp instance.  This class provides
>> methods to control the SIPp instance, and to report on the
>> success/failure of the scenario.
>>
>> * SIPpScenarioSequence - manage a sequential sequence of SIPpScenario
>> executions.  This is useful when you have multiple SIPp scenarios that
>> have slight differences in behavior.
>>
>> There are a number of tests in the Test Suite that make use of these
>> classes - you may want to look at any of the following tests for examples:
>> * info_dtmf
>> * SDP_attribute_passthrough
>> * sip_hold
>> * Any of the sip_custom_presence tests
>>
>> As an aside, if you ever do find yourself only needing the functionality
>> exposed by SIPpTest, the capability to define the test completely in
>> YAML was added to the Test Suite relatively recently.  The
>> channels/SIP/subscribe test demonstrates how to write such a test.
>>

What version of asterisk? Launch asterisk then enter to following on 
another console:

$ asterisk -rx "core waitfullybooted"

You should see: Asterisk has fully booted.

That's how we tell if asterisk is ready to accept testing.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger