[asterisk-dev] [Code Review] Unit test for diaplan pattern matching

Russell Bryant russell at digium.com
Mon Feb 15 07:45:46 CST 2010



> On 2010-02-14 21:08:15, Russell Bryant wrote:
> > /trunk/tests/test_pbx.c, line 21
> > <https://reviewboard.asterisk.org/r/504/diff/4/?file=8110#file8110line21>
> >
> >     "PBX tests" seems so generic.  pbx.h and pbx.c are so overloaded.  What if we just limit this as a module for extension matching specifically?  I imagine that there will be a _lot_ of test cases that we come up with that will justify this test living by itself.
> 
> Mark Michelson wrote:
>     Hmm, well, the idea I had for this module was to make tests which exercise the APIs provided by pbx.[hc]. For now, the only test here is the extension matching test. I figured that more tests could be added to this same module for other aspects of the PBX core. So while your complaint about "PBX tests" being generic makes sense, the idea was for it to be generic on purpose.
> 
> Mark Michelson wrote:
>     One thing I don't think I got across in my comment is that there are likely to be common constructs and functions used by any dialplan tests. As such, keeping them all in one module together helps to reuse code instead of reinventing the wheel for each new test that exercises code from pbx.[hc].

That's fine.  Leave it be.


> On 2010-02-14 21:08:15, Russell Bryant wrote:
> > /trunk/tests/test_pbx.c, line 43
> > <https://reviewboard.asterisk.org/r/504/diff/4/?file=8110#file8110line43>
> >
> >     static const int
> 
> Mark Michelson wrote:
>     My initial inclination was to define this constant that way, but I get the following compiler error when I make that change:
>     
>     [CC] test_pbx.c -> test_pbx.o
>     test_pbx.c:103: error: variably modified ‘priorities’ at file scope
>     make[1]: *** [test_pbx.o] Error 1
>     make: *** [tests] Error 2
>     
>     When I changed back to a #define, compilation goes smoothly.

Ah, interesting.  It blows up when you use the constant within a struct definition.  Oh well, I guess #define it is.


> On 2010-02-14 21:08:15, Russell Bryant wrote:
> > /trunk/tests/test_pbx.c, line 180
> > <https://reviewboard.asterisk.org/r/504/diff/4/?file=8110#file8110line180>
> >
> >     static const char registrar[], instead of *registrar.
> 
> Mark Michelson wrote:
>     Out of curiosity, what is the benefit of one syntax over the other? Does your suggestion add more "constness" to the variable?

It adds more constness, yes.  "static const char foo[]" is equivalent to "static const char * const foo".  You are making the pointer const, as well, instead of just the value it points to.


- Russell


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/504/#review1513
-----------------------------------------------------------


On 2010-02-14 21:47:51, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/504/
> -----------------------------------------------------------
> 
> (Updated 2010-02-14 21:47:51)
> 
> 
> Review request for Asterisk Developers, Jared Smith and lmadsen.
> 
> 
> Summary
> -------
> 
> Here I present a test module for testing pattern matching in the dialplan.
> 
> This is a unit test that runs within Asterisk, so all of the test inputs come from the test code itself. The test is based on a series of arrays that define contexts to create, extensions to place into those contexts, and finally test patterns to run against the dialplan that gets built. The test is designed such that adding new contexts, extensions, or test patterns to the test is as simple as adding new rows of information to arrays. The comments in the test code should be clear enough to show how this is done.
> 
> Currently, the test does not do very much. Only two contexts and three extensions are registered, and four test patterns are attempted to be matched. Right now though, I'm more concerned with the validity of the design of the test itself, as well as its current method of execution. By placing a test with a solid foundation into subversion, even with few actual test cases, people will have easier access to add new test cases as necessary.
> 
> I have placed this test in a new module called tests/test_pbx.c. Within this module, I expect other tests to be implemented which pertain to the PBX core as well. Other suggestions that have arisen during discussions are tests that actually run a PBX on a channel so that it can be ensured that the priorities execute in the proper order and so that statements such as Goto go to the proper place depending on data at the time of its use.
> 
> 
> This addresses bug 16809.
>     https://issues.asterisk.org/view.php?id=16809
> 
> 
> Diffs
> -----
> 
>   /trunk/tests/test_pbx.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/504/diff
> 
> 
> Testing
> -------
> 
> Currently, the test builds the following dialplan (comments added for easy explanation of test pattern matching):
> 
> [test_pattern]
> 
> include => test_pattern_include
> 
> exten => _2.,1,Noop(_2.) ; line 1
> exten => 2000,1,Noop(2000) ; line 2
> 
> [test_pattern_include]
> 
> exten => 2000,2,Noop(2000) ; line 3
> 
> The following test patterns exist:
> 
> 1. exten: 200, context: test_pattern, priority: 1 ; matches line 1 as expected
> 2. exten: 2000, context: test_pattern, priority: 1 ; matches line 2 as expected
> 3. exten: 2000, context: test_pattern, priority: 2 ; matches line 3 as expected
> 4. exten: 2000, context: test_pattern_include, priority: 2 ; matches line 3 as expected
> 
> As stated earlier, this is by no means exhaustive. It is, however, a good starting point and should demonstrate what the test code is capable of. The only capability of the test code that is not demonstrated here is the use of CID matching.
> 
> 
> Thanks,
> 
> Mark
> 
>




More information about the asterisk-dev mailing list