On Wed, Mar 18, 2009 at 11:06 AM, Olle E. Johansson <span dir="ltr">&lt;<a href="mailto:oej@edvina.net">oej@edvina.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
18 mar 2009 kl. 17.57 skrev Gavin Henry:<br>
<div><div></div><div class="h5"><br>
&gt; 2009/3/18 John Lange &lt;<a href="mailto:john@johnlange.ca">john@johnlange.ca</a>&gt;:<br>
&gt;&gt; On Wed, 2009-03-18 at 10:44 -0400, Mihai Balea wrote:<br>
&gt;&gt;&gt; As far as I know, there is no test harness, so it&#39;s not surprising<br>
&gt;&gt;&gt; that regressions pop up as often as they do.<br>
&gt;&gt;<br>
&gt;&gt; I think this is the most important point. There should be a test<br>
&gt;&gt; bench<br>
&gt;&gt; that automatically confirms every (supported) feature is working<br>
&gt;&gt; before<br>
&gt;&gt; it&#39;s released. If the process was automated then it shouldn&#39;t take<br>
&gt;&gt; that<br>
&gt;&gt; long to run the tests.<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; I think this is key and just about every open source project has a<br>
&gt; &quot;make test&quot;.<br>
&gt;<br>
&gt; Take Perl and the CPAN. If your distro doesn&#39;t have a &quot;make test&quot;,<br>
&gt; many people<br>
&gt; won&#39;t use your code, as they have no way of know if your libs work.<br>
&gt;<br>
&gt; I&#39;m part of the OpenLDAP project and our Release &amp; QA Engineer does<br>
&gt; all this.<br>
&gt;<br>
&gt; Does Asterisk have one/somebody?<br>
&gt;<br>
&gt; Our Release &amp; QA Engineer makes sure all the right patches are<br>
&gt; applied to the<br>
&gt; CVS branch and calls for testing. Our &quot;make test&quot; runs around 55<br>
&gt; tests, but as usual<br>
&gt; could do with many, many more. But this means we don&#39;t release if<br>
&gt; there is a failure<br>
&gt; and don&#39;t have any regressions.<br>
&gt;<br>
&gt; I understand * will be hard to develop a test suite for, but we should<br>
&gt; at least try to have a<br>
&gt; test for every feature listed here:<br>
&gt;<br>
&gt; <a href="http://www.asterisk.org/support/features" target="_blank">http://www.asterisk.org/support/features</a><br>
&gt;<br>
&gt; We could do virtualisation different architures etc. dependant on the<br>
&gt; feature we are testing or<br>
&gt; even do smoke testing etc. I don&#39;t know, but it would be good to know<br>
&gt; it works before it is<br>
&gt; released. We may even need virtual devices etc.<br>
&gt;<br>
&gt; Another great example is the Samba project:<br>
&gt;<br>
&gt; <a href="http://build.samba.org/" target="_blank">http://build.samba.org/</a><br>
&gt;<br>
&gt; People or companies interested in seeing their kit and/or platform<br>
&gt; supported add a node to the build<br>
&gt; farm and send the results in.<br>
&gt;<br>
&gt; If the test suite is deployed like this, people desperate for testing<br>
&gt; will add their servers.<br>
&gt;<br>
</div></div>If you search the mailing lists, you will see that this has been<br>
brought forward<br>
a large number of times. There has been efforts by mutliple developers<br>
to start<br>
with a test framework. The work that is in the code today is mostly<br>
murf&#39;s<br>
test suite for the AEL parse and a few others.<br>
<br>
Digium also runs a few test servers that run build tests, but not<br>
function tests<br>
as far as I know.</blockquote><div><br>I&#39;ll throw in a few opinions on this issue-- Some of the software mentioned<br>with nice test suites are pretty easy to run tests against. In all the <br>cases, it&#39;s pure software involved, and you define nice input-output-compare<br>
tests to insure no regressions arise.<br><br>But asterisk is quite challenging. To do it right, I picture electro-mechanical<br>devices that will pick up a handset and dial physical analog phones, supplying<br>standard sound sequences, and recording sound into files. Maybe<br>
such a robotic phone is available for analog lines.  For sip phones, a client<br>that can be driven &#39;robotically&#39;, under the control of some sort of script language,<br>or via a command driven network interface, like the manager interface, so you<br>
can script up dozens of standard calling squences involving parking, xfers, call files,<br>with all their permutations of eg. hookflash, call features, sip phone buttons, etc.<br><br>You&#39;d need sound file comparators that would judge sent-vs-received quality loss,<br>
echo level, dialplan scripts to run the tests and look for problems in real time, etc. It&#39;s a <br>mind-boggling task! Any part of it is do-able, but wow! Testing a program like Asterisk<br>with so many possible ins and outs will be a real challenge!<br>
<br>I&#39;ve built dozens of large complex commercial products that I had to maintain for years, with<br>highly critical customers in the thousands and testing was an absolute requirement... <br><br>murf<br><br>A great project for any PBX. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you can step forward and help us build a foundation for a test<br>
suite, it will<br>
be extremely appreciated!<br>
<font color="#888888"><br>
/Olle<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Steve Murphy<br>ParseTree Corp<br><br>