I'm saying this because the should:notTakeMoreThan: has some interesting implementation details, like running the test in another process and synchronizing them, etc... so running all the test would create a process for each test, etc. tacking more time�unnecessarily�in most of the cases... unless the implementation takes care of only doing this special "feature" when needed (for example, when you have that pragma) but the, if you have to write the pragma why not just send the message #should:notTakeMoreThan: and problem solved?

On Sat, May 29, 2010 at 3:42 PM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:

For me the point is that I have the impression that this is an interesting feature to have
when we have a test server. Like that you make sure that you do not have tests with infinite recursion
now this is also true that on a test server you do not really care if your tests take 30s or 2 min.

Stef

> We already have #should:notTakeMoreThan: and friends in TestCase. The
> complete TestCase can be protected by overriding #runCase, the
> individual test by wrapping the code of the test method.
>
> Lukas
>
> On 29 May 2010 16:43, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
>> Stef,
>>
>> Time to expose some of my ignorance (don't worry, I have plenty more waiting where I found this): what is the tag concept? �That sounds very Tweak-ish, and I am a real believer in doing things "with the language, not TO the language" whenever possible. �That is not to say that frameworks are bad; in fact, it means that frameworks are good, language extensions are anywhere from suspect to evil.
>>
>> I have some code that I am still porting, but the basic idea is to be able to write
>>
>> [
>> � "code that might not complete"
>>
>> ] tryForSeconds:10 onTimeOut:[
>>
>> ].
>>
>> With a robust capability to do such things, it is probably not necessary (or even appropriate) for TestCase to enforce timeouts. �The timeout block can simply raise an exception or assert false, and there is no need to disable timeouts where they do not belong.
>>
>> Bill
>>
>> ________________________________________
>> From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Roberts [mike@mjr104.co.uk]
>> Sent: Saturday, May 29, 2010 6:17 AM
>> To: Pharo-project@lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] SUnit Time out
>>
>> yes think it's a good idea. I'm not sure the granularity that's
>> required though.
>>
>> mike
>>
>> On Saturday, May 29, 2010, stephane ducasse <stephane.ducasse@free.fr> wrote:
>>> Hi guys
>>>
>>> in Squeak andreas introduced the idea of test time out
>>> Do you think that this is interesting?
>>>
>>> Stef
>>>
>>> SUnit
>>> -----
>>> 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 <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method.
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project