[asterisk-dev] [Code Review] Add an option to the test suite that makes it believe that the version of Asterisk under test is some other version

opticron reviewboard at asterisk.org
Wed Nov 21 11:00:53 CST 2012


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



/asterisk/trunk/runtests.py
<https://reviewboard.asterisk.org/r/2202/#comment14214>

    Why wouldn't this just be passed in from the TestSuite class (the only instantiator of TestRun)?  It's probably better to avoid parsing it twice.


- opticron


On Nov. 20, 2012, 12:11 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2202/
> -----------------------------------------------------------
> 
> (Updated Nov. 20, 2012, 12:11 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> At first glance, this patch sounds stupid at best, harmful at worst.  However, there is a purpose to it...
> 
> The Asterisk Test Suite has to "understand" Asterisk version numbers.  It uses the version reported by the installed Asterisk to determine if a test can run.  In general, this is used so that tests written against Asterisk 10 don't execute when the version of Asterisk is 1.8 (and in other similar cases).  This mechanism works great for Asterisk version branches and tags (minus all of the usual shenanigans that ensue given all of the ways in which we've changed the Asterisk versioning scheme).
> 
> Trunk gets a little funky.  We treat trunk as being greater then, well, everything.  Fair enough.
> 
> Team branches are worse.  What is mjordan-cool-branch?  How do you know that branch was based off of 1.8, 10, 11, or trunk?  Inspecting subversion properties for the information gets complicated, and puts some constraints on the Test Suite that we're trying to avoid.  Currently, we treat team branches as being equivalent to trunk.  That works for any team branch that is being used to develop new features against trunk.
> 
> This doesn't work if the team branch is actually related to 1.8, or some other version of Asterisk.  If you install a team branch that is based on 1.8, all tests will be executed - including those that require features developed in later versions of Asterisk.  Those tests will fail spectacularly, making it very difficult to tell if your branch has legitimate issues.
> 
> Rather then trying to manipulate the version parsing schemes (again), this patch adds an option to the test configurations that allow them to override the Asterisk version under test.  In the top level test-config.yaml, define:
> 
> properties:
>   forced-version: 1.8.11.1
> 
> Or some other version you'd like to make the Test Suite think its running against.
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/lib/python/asterisk/TestConfig.py 3508 
>   /asterisk/trunk/runtests.py 3508 
>   /asterisk/trunk/test-config.yaml 3508 
> 
> Diff: https://reviewboard.asterisk.org/r/2202/diff
> 
> 
> Testing
> -------
> 
> Used the forced-version to make the Test Suite think it was running against 1.8.0.0.  Checked out a team branch based on trunk, compiled, installed, and attempted to run a ConfBridge test (confbridge_marked).  Test refused to run, because it thought it was running against 1.8.  Removed the forced-version; test ran.
> 
> 
> Thanks,
> 
> Matt
> 
>

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


More information about the asterisk-dev mailing list