[asterisk-dev] [Code Review]: Generic AMI Module for Events

Tue Jul 10 09:54:53 CDT 2012

> On July 10, 2012, 9:37 a.m., Matt Jordan wrote:
> > /asterisk/team/mmichelson/bridge-tests/lib/python/asterisk/TestRunner.py, lines 102-105
> > <https://reviewboard.asterisk.org/r/2013/diff/3/?file=29956#file29956line102>
> >
> >     This will still append the test path to the Python module search path for every single test that loads any additional modules beyond the Test Object, even if that module is in the lib.python.asterisk package.
> >     
> >     With the 'load-from-test' option being handled down on line 187, did you mean to keep this?

No, I had meant to delete this.

> On July 10, 2012, 9:37 a.m., Matt Jordan wrote:
> > /asterisk/team/mmichelson/bridge-tests/lib/python/asterisk/TestRunner.py, lines 191-195
> > <https://reviewboard.asterisk.org/r/2013/diff/3/?file=29956#file29956line191>
> >
> >     It seems a little odd to me that we're specifying 'load-from-test' in the Test Object configuration, when in reality that will affect the other loadable modules, not the test object.  In fact, the test object has already been loaded into memory before this is parsed.
> >     
> >     Maybe we should just change this configuration option to be 'search-in-test' or something that implies that the modules can be located in the test directory, as well as lib.python.asterisk?

Yeah, load-from-test doesn't really pertain to the test-object itself, but more the test overall.

I didn't like handling it in the module configuration because it may be (and likely will be once bridging tests start being written) that multiple modules may be located in the test directory. I didn't like the idea of having:

test-modules:
    test-object:
        typename: 'SimpleTestCase.SimpleTestCase'
    modules:
        -
            load-from-test: 'True'
            typename: 'Alfa.Bravo'
        -
            load-from-test: 'True'
            typename: 'Charlie.Delta'

The two load-from-test lines are redundant. Instead, the whole test should be told that loading from the test path is true. Perhaps the 'load-from-test' or 'search-in-test' option should be an option on the level of 'test-modules' and not inside the test-object or modules configuration?

Consider something like this:

test-modules:
    load-from-test: 'True'
    test-object:
        typename: 'SimpleTestCase.SimpleTestCase'
    modules:
        -
            typename: 'Alfa.Bravo'
        -
            typename: 'Charlie.Delta'

I also feel like 'load-from-path' should be up for the same consideration.

- Mark

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

On July 10, 2012, 9:16 a.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2013/
> -----------------------------------------------------------
> 
> (Updated July 10, 2012, 9:16 a.m.)
> 
> 
> Review request for Asterisk Developers and Matt Jordan.
> 
> 
> Summary
> -------
> 
> This is a new pluggable module for the Asterisk test suite intended to be used to verify AMI events.
> 
> There are two ways that this may be used.
> 
> * "headermatch": This is the simpler of the two methods. When user-specified conditions are met, then headers in an AMI event are checked for expected values. If the check fails, then the test fails as well.
> * "callback": For cases where more complicated checks are required than just AMI headers, then a user-defined callback may be called instead. This allows for the user to maintain their own test state to determine if the test has passed or failed.
> 
> There are some changes made outside the AMI module as well.
> 
> * TestCase has been updated to have a set_passed() method. Instead of directly modifying the 'passed' field of a test object, this method should be called. This way, if one module fails, other modules cannot override the failed state of the test. The CDR and ForkCDR modules have been updated accordingly
> * TestRunner has been modified to get rid of the "load-from-test" option. Instead, when module configuration is loaded, it automatically loads the test path into its loader's supported paths. This was done to get around a situation where I wanted the test path added to the supported paths but did not want the TestRunner to actually load the module in that path.
> 
> I have also included a sample YAML file that details the options available for the AMI module.
> 
> 
> Diffs
> -----
> 
>   /asterisk/team/mmichelson/bridge-tests/lib/python/asterisk/asterisk.py 3290 
>   /asterisk/team/mmichelson/bridge-tests/lib/python/asterisk/TestCase.py 3290 
>   /asterisk/team/mmichelson/bridge-tests/lib/python/asterisk/TestRunner.py 3290 
>   /asterisk/team/mmichelson/bridge-tests/lib/python/asterisk/ami.py 3290 
>   /asterisk/team/mmichelson/bridge-tests/lib/python/asterisk/cdr.py 3290 
>   /asterisk/team/mmichelson/bridge-tests/sample-yaml/ami-config.yaml.sample PRE-CREATION 
>   /asterisk/team/mmichelson/bridge-tests/tests/cdr/ForkCdrModule.py 3290 
>   /asterisk/team/mmichelson/bridge-tests/tests/predial/configs/ast1/extensions.conf PRE-CREATION 
>   /asterisk/team/mmichelson/bridge-tests/tests/predial/configs/ast1/followme.conf PRE-CREATION 
>   /asterisk/team/mmichelson/bridge-tests/tests/predial/run-test PRE-CREATION 
>   /asterisk/team/mmichelson/bridge-tests/tests/predial/test-config.yaml PRE-CREATION 
>   /asterisk/team/mmichelson/bridge-tests/tests/tests.yaml 3290 
> 
> Diff: https://reviewboard.asterisk.org/r/2013/diff
> 
> 
> Testing
> -------
> 
> I tested this by tweaking the cdr_userfield test with different values. The only option that is not thoroughly tested is the 'id' field since SimpleTestCase only uses a single Asterisk instance. The intention, once this gets committed, is to use this in a battery of Bridging tests that will be written in the near future.
> 
> 
> Thanks,
> 
> Mark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120710/ca6fa02e/attachment.htm>