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

[nitesh bansal]

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.
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121004/0e7185b3/attachment.htm>