I completely agree <br><br><div class="gmail_quote">On Sun, May 30, 2010 at 2:52 PM, Chris Muller <span dir="ltr">&lt;<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
(Copying squeak-dev too).<br>
<br>
I&#39;m not sold on the whole test timeout thing.  When I run tests, I<br>
want to know the answer to the question, &quot;is the software working?&quot;<br>
<br>
Putting a timeout on tests trades a slower, but definitive, &quot;yes&quot; or<br>
&quot;no&quot; for a supposedly-faster &quot;maybe&quot;.  But is getting a &quot;maybe&quot; back<br>
really faster?  I&#39;ve just incurred the cost of running a test suite,<br>
but left without my answer.  I get a &quot;maybe&quot;, what am I supposed to do<br>
next?  Find a faster machine?  Hack into the code to fiddle with a<br>
timeout pragma?  That&#39;s not faster..<br>
<br>
But, the reason given for the change was not for running tests<br>
interactively (the 99% case), rather, all tests form the beginning of<br>
time are now saddled with a timeout for the 1% case:<br>
<div class="im"><br>
  &quot;The purpose of the timeout is to catch issues like infinite loops,<br>
unexpected user input etc. in automated test environments.&quot;<br>
<br>
</div>If tests are supposed to be quick (and deterministic) anyway, wouldn&#39;t<br>
an infinite loop or user-input be caught the first time the test was<br>
run (interactively)?  Seriously, when you make software changes, we<br>
run the tests interactively first, and then the purpose of night-time<br>
automated test environment is to catch regressions on the merged<br>
code..<br>
<br>
In that case, the high-level test-controller which spits out the<br>
results could and should be responsible for handling &quot;unexpected user<br>
input&quot; and/or putting in a timeout, not each and every last test<br>
method..<br>
<br>
IMO, we want short tests, so let&#39;s just write them to be short.  If<br>
they&#39;re too long, then the encouragement to shorten them comes from<br>
our own impatience of running them interactively.  Running them in<br>
batch at night requires no patience, because we&#39;re sleeping, and<br>
besides, the batch processor should take responsibility for handling<br>
those rare scenarios at a higher-level..<br>
<br>
Regards,<br>
  Chris<br>
<br>
<br>
On Sat, May 29, 2010 at 2:53 AM, stephane ducasse<br>
<div class="im">&lt;<a href="mailto:stephane.ducasse@free.fr">stephane.ducasse@free.fr</a>&gt; wrote:<br>
</div><div><div></div><div class="h5">&gt; Hi guys<br>
&gt;<br>
&gt; in Squeak andreas introduced the idea of test time out<br>
&gt; Do you think that this is interesting?<br>
&gt;<br>
&gt; Stef<br>
&gt;<br>
&gt; SUnit<br>
&gt; -----<br>
&gt; All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the &lt;timeout: seconds&gt; tag or for an entire test case by implementing the #defaultTimeout method.<br>

&gt; _______________________________________________<br>
&gt; Pharo-project mailing list<br>
&gt; <a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>
&gt; <a href="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project" target="_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project</a><br>
&gt;<br>
<br>
</div></div></blockquote></div><br>