[asterisk-dev] [Code Review]: Add test execution modes to the Asterisk Testsuite

Tue Sep 20 13:10:09 CDT 2011

> On Sept. 20, 2011, 12:27 p.m., Matthew Nicholson wrote:
> > /asterisk/trunk/README.txt, line 344
> > <https://reviewboard.asterisk.org/r/1447/diff/1/?file=20790#file20790line344>
> >
> >     Is there a way to use some sort of short hand for these extremely long condition names?
> 
> mjordan wrote:
>     Nope.
>     
>     We need the python module name (the thing after the first .) and the class name for the introspection to properly lookup the object to dynamically create.  The 'asterisk' is in there because our python system library path doesn't append that folder to it, and changing that would affect a lot of import statements throughout the code.
> 
> Paul Belanger wrote:
>     I would agree.  I like where we are going, however we are starting to make it complex for writing a test config file.  I would must rather see:
>     
>     reports:
>        Threads: yes
>        SIPDialogs: yes
>           Ignore: 'netconsole'
>           ...
>     
>     Then the test suite is responsible for building up the conditions.  At this point, I'm not sure why or how a Pre / Post check condition for Threads could be different or changed.
> 
> mjordan wrote:
>     Well, we either specify the objects to create in the configuration and do it dynamically, or we hard code them in TestCase.  I had them hard coded originally, but that made adding new ones rather tough on the developer - they had to find the correct place in the base class and add all the right callbacks and hooks to have them added correctly and not break things.
>     
>     I can go with that approach instead of that's what people would like.
> 
> mjordan wrote:
>     Whoops, wrong class.  They'd be hard coded in TestConditions.
> 
> Paul Belanger wrote:
>     :p If you are getting confused, we are in trouble :D Kidding.
>     
>     I don't know the best approach to take, will let you make the call, but if we can make the configuration file more simple I think it will be better.  We should just be passing a flag to enable / disable the thread tests, and the testsuite takes care of the rest.

If you know that what you're doing is specifying the name of the object to create, I don't think what we have is very difficult or cumbersome.  Is it longer then just a 'yes' or 'no'?  Sure.  But it also gives us the capability to not have to go digging into base classes to find the right place - and the right method calls - to register a new pre- / post-test condition.  That's pretty handy - particularly since I'm not going to be the only person writing them (I hope).

As far as having to do test configuration files, this patch makes it less of a burden by defining the pessimistic mode checks in a top level file, so that they are only defined once.  As a test writer, you should test your test case in pessimistic mode to determine - with the defaults - what checks pass and fail.  If you have checks that fail, and they are not issues with Asterisk, you can override the default behavior in your test-config.yaml file.  In that case, you will need to redefine the pre / post-test conditions that you need to override - but Ctrl+C / Ctrl+V works just as fast for 30 characters as it does for 5 (and if you're retyping everything and not just the stuff you need, well, then, I can't help you).

- mjordan

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

On Sept. 19, 2011, 2:22 p.m., mjordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1447/
> -----------------------------------------------------------
> 
> (Updated Sept. 19, 2011, 2:22 p.m.)
> 
> 
> Review request for Asterisk Developers and Paul Belanger.
> 
> 
> Summary
> -------
> 
> This patch adds the ability for global 'modes' to be defined for the Asterisk test-suite.  Those settings in a mode can then be applied either at the base level in the runtests.py script, or by any test that inherits from TestClass.py.  As the global settings file makes use of the TestConfig class, all settings in the TestConfig class can theoretically be applied on a global scale - although since each test checks its dependencies independently, only the Test Conditions are currently useful.
> 
> One additional settings was added - exclude-tests.  This lets the global settings file explicitly call out tests (or subsets of tests) to not run without having to modify the tests.yaml file, and acts as a counterpart to the --test command line flag.
> 
> The only assumption made by this patch is that the global settings file is named 'test-config.yaml' and is located at the current run directory (the location of the runtests.py script).
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/README.txt 2346 
>   /asterisk/trunk/lib/python/asterisk/TestCase.py 2346 
>   /asterisk/trunk/lib/python/asterisk/TestConfig.py 2346 
>   /asterisk/trunk/runtests.py 2346 
>   /asterisk/trunk/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/apps/voicemail/authenticate_extensions/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/authenticate_invalid_mailbox/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/authenticate_invalid_password/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/authenticate_nominal/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_callback/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_delete/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_dialout/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_envelope/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_new_user/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_nominal/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_reply/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/func_vmcount/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/leave_voicemail_external_notification/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/leave_voicemail_forwarding/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/leave_voicemail_forwarding_auto_urgent/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/leave_voicemail_nominal/test-config.yaml 2346 
>   /asterisk/trunk/tests/apps/voicemail/leave_voicemail_priority/test-config.yaml 2346 
> 
> Diff: https://reviewboard.asterisk.org/r/1447/diff
> 
> 
> Testing
> -------
> 
> Tested fast config mode, standard config mode, and pessimistic config mode.  Each worked as intended:
> * Fast config mode successfully excluded those tests with a reactor_timeout greater than one minute
> * Standard config mode applied no global settings
> * Pessimistic config mode applied the Test Conditions to all tests inheriting from TestCase.  Those tests that further defined test specific overrides applied those settings over the global conditions.
> 
> 
> Thanks,
> 
> mjordan
> 
>

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