Oh wait I see in the first message in this thread you have self timeLimit: 10 seconds
Paul DeBruicker wrote > How do you propose raising the limit for a specific test would go? > > Pragma? > Denis Kudriashov wrote >> Super!!! It's integrated (In 60201). Thank's integrators. >> >> Now we need correct default time limit and mark long tests as long. I >> opened new issue 19035 >> <https://pharo.fogbugz.com/f/cases/19035/Default-time-limit-for-tests-should-be-small> >> . >> What you think about default value? I would use 200 milliseconds. >> >> 2016-08-31 14:10 GMT+02:00 Denis Kudriashov < >> dionisiydk@ >> >: >> >>> Hi. >>> >>> I am working on SUnit improvements. I open issue 19015 >>> <https://pharo.fogbugz.com/f/cases/19015/Tests-should-never-hang-and-leave-forked-processes-live>. >>> Slice is inbox which waits your review and feedback. >>> I was trying to address three problems: >>> >>> *1) Tests should never hang. They should be always executed within time >>> limit.* >>> >>> I give them 10 minutes for now to not change existing behaviour of >>> tests. >>> At next step it should be really reduced to ~100 milliseconds (?). >>> Any TestCase could redefine time limit by method #defaultTimeLimit. >>> Or it could be specified directly in test code by >>> self timeLimit: 10 seconds >>> (could be changed at any time of test execution). >>> >>> To implement this logic special watch dog process is running for given >>> test suite to control execution time of tests. It is single process for >>> full test suite. >>> >>> *2) When test completes all forked processes should be terminated.* >>> >>> If your tested code produced zombie processes SUnit will take care about >>> destroying all such garbage. >>> (it not means that you don't need to clean table in #tearDown but any >>> code >>> could be broken and running tests should not produce dirty system). >>> >>> *3) Any failures inside forked processes should not spawn debugger while >>> running tests.* >>> Only when we debug tests we need debugger on forked failed processes. >>> During normal run SUnit should prevent such "background debuggers" and >>> mark such tests as failed. >>> >>> To implement this behaviour SUnit will handle errors from forked >>> processes >>> by suspending them and collecting them in special collection. >>> I introduce TestFailedByForkedProcess error to signal these kind of >>> problems at the end of tests. This error is resumable and resume will >>> opens >>> debuggers of suspended failures (in fact it will resume suspended >>> processes). >>> So to debug background failures you will need extra Proceed action on >>> debugger when TestFailedByForkedProcess is signalled. >>> But in normal run such tests will be just failed by >>> TestFailedByForkedProcess error. >>> >>> *Now details on how it is done:* >>> >>> I introduce special process specific variable >>> CurrentExecutionEnvironment. >>> It is not installed by default and as default value it returns >>> DefaultExecutionEnvironment instance. >>> This variable is inheritable. If your install concrete environment into >>> process it will be installed to any child process. >>> >>> So value of variable is instance of ExecutionEnvironment subclasses and >>> you can install it by: >>> >>> anYourExecutionEnvironment beActiveDuring: aBlock >>> >>> >>> When block completes previous environment is restored. >>> For default environment there is class side method: >>> >>> DefaultExecutionEnvironment beActiveDuring: aBlock >>> >>> >>> And to reset current environment to default: >>> >>> DefaultExecutionEnvironment beActive. >>> >>> >>> SUnit introduces TestExecutionEnvironment which implements all described >>> behaviour for time limits and forked processes. >>> To activate environment there is new method #runCaseManaged. And >>> submitted >>> slice uses it instead of simple runCase. >>> >>> TestCase>>runCaseManaged >>> CurrentExecutionEnvironment runTestCase: self >>> >>> >>> DefaultExecutionEnvironment will install new TestExecutionEnvironment >>> and >>> delegate processing to it. And if TestExecutionEnvironment is already >>> active it will just process new test case. >>> >>> Now monkey has problem in checking slice (annoying timeout for loading). >>> So I can't see real system impact. But it should not stop you from >>> review >>> :)) >>> I think it is very important features for all our tests. And environment >>> idea will lead to very interesting future. >>> >>> Best regards, >>> Denis >>> -- View this message in context: http://forum.world.st/SUnit-improvements-need-review-and-feedback-tp4913413p4913960.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
