[asterisk-dev] [Code Review]: TestSuite pre- and post-test condition check framework

mjordan reviewboard at asterisk.org
Mon Sep 12 12:52:10 CDT 2011 


> On Sept. 12, 2011, 12:39 p.m., Paul Belanger wrote:
> > /asterisk/trunk/lib/python/asterisk/buildoptions.py, lines 34-38
> > <https://reviewboard.asterisk.org/r/1430/diff/1/?file=20546#file20546line34>
> >
> >     Hmm... we should see about exposing this information directly in Asterisk, either the CLI / AMI or both.  I'd like to get away from needing the actually asterisk source code as a dependency.
> >     
> >     But, this maybe a future change too.

We may want to file a JIRA task for that as an improvement to Asterisk.


> On Sept. 12, 2011, 12:39 p.m., Paul Belanger wrote:
> > /asterisk/trunk/lib/python/asterisk/ThreadTestCondition.py, line 72
> > <https://reviewboard.asterisk.org/r/1430/diff/1/?file=20545#file20545line72>
> >
> >     Again, future enhancement for Asterisk.  Exposing this information via the AMI.

It'd be nicer than parsing CLI return values.  Most of these pre- / post-checks are going to need to do this as well.


> On Sept. 12, 2011, 12:39 p.m., Paul Belanger wrote:
> > /asterisk/trunk/tests/apps/voicemail/authenticate_nominal/test-config.yaml, lines 10-17
> > <https://reviewboard.asterisk.org/r/1430/diff/1/?file=20551#file20551line10>
> >
> >     This is good for now, however once we are confident on well this logic is going to work, I would rather not have to define this for every tests.
> >     
> >     This will help reduce the maintenance cost for tests.

Agreed.  Since the module path is being used to dynamically create these - and its a lot easier to 'place' the new condition checks in the yaml file then having to find the correct place in TestClass / TestConditionController / whatever - I think once we have some confidence that all the tests are working well with this, I'd go with:
1. Define the pre- post- tests in the top level .yaml file
2. Use the test configs to individually override them, if desired (such as setting a single test condition to pass / fail)

There'd have to be some additional logic to know that a test config is overriding another, etc. - but for a future enhancement I don't think it would be too bad.


- mjordan


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


On Sept. 12, 2011, 12:01 p.m., mjordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1430/
> -----------------------------------------------------------
> 
> (Updated Sept. 12, 2011, 12:01 p.m.)
> 
> 
> Review request for Asterisk Developers and Paul Belanger.
> 
> 
> Summary
> -------
> 
> This patch provides a framework for doing pre- and post-test condition checking for an individual test run.  This allows a test to take a snapshot of the state of its Asterisk instances before it executes and compare that against a snapshot of its Asterisk instances after the test executes.  Depending on the test configuration, the test can either pass or fail based on whether or not resources were left uncollected in Asterisk after test execution.
> 
> The place in the test workflow where the conditions are evaluated is shown below:
> main                   ConcreteTest   TestClass       TestConditionController
>  test.start_asterisk ----------------->start_asterisk
>                                          
>  reactor.run -------------> run
>                              |--------> run
>                                          |------------>evaluate_pre_checks()
>                                          |
> 
>  test.stop_asterisk ------------------>stop_asterisk
>                                          |------------>evaluate_post_checks()
>                                          | 
> 
> All pre- and post-test condition objects must inherit from the class TestCondition.  The objects are created dynamically using python reflection and registered as either a pre- or post- check based on the test-config.yaml file for each test.  Post TestConditions can be set to reference the Pre-Test condition object, such that the object is supplied to the post-test object during its evaluation.  This allows the post-test condition object to make its evaluation based on the initial state of Asterisk as captured by the pre-test object.  TestConditions are also allowed to have 'expected failure' states set to them, in case the tests in question are known to fail.
> 
> As part of this patch, a TestCondition set of objects were made to check for thread usage in Asterisk after a test.  The objects ensure that after a test run, the threads currently active in Asterisk are the same threads that were active prior to the test run.  The voicemail tests were updated to use this as an example.
> 
> Additionally, a few other enhancements were included with this patch:
> 1. A new class that allows tests to check what build options Asterisk was compiled with
> 2. Specifying the --test option now allows for a path to be specified as opposed to a specific test.  All tests under that path will be executed, e.g., --test=tests/channels/SIP/ will execute all SIP tests
> 3. XML returned by runtests.py now includes ERROR log statements in the Failure message attribute
> 4. Test configuration was moved to its own class in the asterisk libraries.  All TestClass-derived tests now have access to their configuration locally.
> 5. SIPpVersion was moved to the asterisk directory, as the other sipp related classes were already there and the TestConfig class in asterisk needed to reference it
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/lib/python/asterisk/ThreadTestCondition.py PRE-CREATION 
>   /asterisk/trunk/lib/python/asterisk/buildoptions.py PRE-CREATION 
>   /asterisk/trunk/lib/python/asterisk/TestState.py 2176 
>   /asterisk/trunk/lib/python/asterisk/TestConditions.py PRE-CREATION 
>   /asterisk/trunk/lib/python/asterisk/TestConfig.py PRE-CREATION 
>   /asterisk/trunk/lib/python/asterisk/TestCase.py 2176 
>   /asterisk/trunk/lib/python/asterisk/sippversion.py PRE-CREATION 
>   /asterisk/trunk/lib/python/sipp/version.py 2090 
>   /asterisk/trunk/runtests.py 2090 
>   /asterisk/trunk/tests/apps/voicemail/authenticate_nominal/run-test 2177 
>   /asterisk/trunk/tests/apps/voicemail/authenticate_nominal/test-config.yaml 2094 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_new_user/configs/ast1/extensions.conf 2094 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_new_user/run-test 2176 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_new_user/test-config.yaml 2094 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_nominal/configs/ast1/extensions.conf 2094 
>   /asterisk/trunk/tests/apps/voicemail/check_voicemail_nominal/test-config.yaml 2094 
>   /asterisk/trunk/tests/apps/voicemail/func_vmcount/configs/ast1/extensions.conf 2094 
>   /asterisk/trunk/tests/apps/voicemail/func_vmcount/test-config.yaml 2094 
>   /asterisk/trunk/tests/apps/voicemail/leave_voicemail_nominal/test-config.yaml 2094 
> 
> Diff: https://reviewboard.asterisk.org/r/1430/diff
> 
> 
> Testing
> -------
> 
> trunk on local system.
> 
> 
> Thanks,
> 
> mjordan
> 
>

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

More information about the asterisk-dev mailing list