[Pharo-project] Deadlock detection for testcases
Hi: Have currently a lot of trouble with tests which are just deadlocking. Here is quick hack which specifies a timeout for test cases. Maybe it is useful for others, too. Any suggestions for improvement are welcome. Best Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
Cool. I cc Adrian Kuhn that maybe he is interested. Cheers Mariano 2010/1/22 Stefan Marr <pharo@stefan-marr.de>
Hi:
Have currently a lot of trouble with tests which are just deadlocking.
Here is quick hack which specifies a timeout for test cases. Maybe it is useful for others, too. Any suggestions for improvement are welcome.
Best Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr <http://soft.vub.ac.be/%7Esmarr> Phone: +32 2 629 3956 Fax: +32 2 629 3525
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jan 22, 2010, at 12:39 AM, Stefan Marr wrote:
Hi:
Have currently a lot of trouble with tests which are just deadlocking.
Here is quick hack which specifies a timeout for test cases. Maybe it is useful for others, too. Any suggestions for improvement are welcome.
maybe you can use #valueWithin:onTimeout: ? This is defined on blocks. "Evaluate the receiver. If the evaluation does not complete in less than aDuration evaluate the timeoutBlock instead" Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Hi Marcus: On 22 Jan 2010, at 09:59, Marcus Denker wrote:
On Jan 22, 2010, at 12:39 AM, Stefan Marr wrote:
Hi:
Have currently a lot of trouble with tests which are just deadlocking.
Here is quick hack which specifies a timeout for test cases. Maybe it is useful for others, too. Any suggestions for improvement are welcome.
maybe you can use #valueWithin:onTimeout: ? This is defined on blocks.
Ok, then it looks like: runCase "STEFAN: Added simple hack to 'detect' deadlocks" Author ifUnknownAuthorUse: 'TestRunner' during: [ [ [self setUp. self performTest.] valueWithin: self expectedMaxRuntime onTimeout: [ self failWithTimeout. ]] ensure: [ self tearDown. self cleanUpInstanceVariables ] ] And works fine, too. Thanks Stefan
"Evaluate the receiver. If the evaluation does not complete in less than aDuration evaluate the timeoutBlock instead"
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
Ok, then it looks like:
runCase     "STEFAN: Added simple hack to 'detect' deadlocks"     Author         ifUnknownAuthorUse: 'TestRunner'         during: [             [ [self setUp.              self performTest.]                     valueWithin: self expectedMaxRuntime                     onTimeout: [ self failWithTimeout. ]]                 ensure: [                     self tearDown.                     self cleanUpInstanceVariables ] ]
And works fine, too.
Please don't add this to TestCase. Sometimes I want to keep my debuggers open. Also this slows running lots of tests considerably down. I suggest that you create your own subclass of TestCase and override runCase as such: runCase [ super runCase ] valueWithin: self expectedMaxRuntime onTimeout: [ self failWithTimeout ] Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli <renggli@...> writes: Please don't add this to TestCase. Sometimes I want to keep my
debuggers open. Also this slows running lots of tests considerably down.
I suggest that you create your own subclass of TestCase and override runCase as such:
runCase [ super runCase ] valueWithin: self expectedMaxRuntime onTimeout: [ self failWithTimeout ]
+1, being able to debug your tests is a must have. Please note that is also TAssertable >> #should:notTakeMoreThan: TAssertable >> #should:notTakeMoreThanMilliseconds: TestMatcher >> #runWithin: If you dont use akuhn/SUnit the first two methods are in TestCase and the third requires Phexample. cheers, AA
we should evaluate what adrian did and integrate it! Stef On Jan 23, 2010, at 1:03 AM, Adrian Kuhn wrote:
Lukas Renggli <renggli@...> writes:
Please don't add this to TestCase. Sometimes I want to keep my
debuggers open. Also this slows running lots of tests considerably down.
I suggest that you create your own subclass of TestCase and override runCase as such:
runCase [ super runCase ] valueWithin: self expectedMaxRuntime onTimeout: [ self failWithTimeout ]
+1, being able to debug your tests is a must have.
Please note that is also
TAssertable >> #should:notTakeMoreThan: TAssertable >> #should:notTakeMoreThanMilliseconds: TestMatcher >> #runWithin:
If you dont use akuhn/SUnit the first two methods are in TestCase and the third requires Phexample.
cheers, AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse <stephane.ducasse@...> writes:
we should evaluate what adrian did and integrate it!
In February I am back from deadline hunting and ready to help with the integration. Deadline-driven research is so ... gosh, cant we just abandon it? BTW, Lance Fortnow on why the conference model in CS is no longer sustainable, http://bit.ly/P3jfv --AA -- SUITE 2010, 2nd Workshop on search in software engineering. Extended deadline to next Friday, January 29, http://bit.ly/suite2010
In February I am back from deadline hunting and ready to help with the integration.
I'm cleaning my plate (just one more project to write :(....
Deadline-driven research is so ... gosh, cant we just abandon it?
don't tell me :)
BTW, Lance Fortnow on why the conference model in CS is no longer sustainable, http://bit.ly/P3jfv
--AA
-- SUITE 2010, 2nd Workshop on search in software engineering. Extended deadline to next Friday, January 29, http://bit.ly/suite2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi: On 23 Jan 2010, at 01:03, Adrian Kuhn wrote:
Lukas Renggli <renggli@...> writes:
Please don't add this to TestCase. Sometimes I want to keep my
debuggers open. Also this slows running lots of tests considerably down.
I suggest that you create your own subclass of TestCase and override runCase as such:
runCase [ super runCase ] valueWithin: self expectedMaxRuntime onTimeout: [ self failWithTimeout ]
+1, being able to debug your tests is a must have.
Please note that is also
TAssertable >> #should:notTakeMoreThan: TAssertable >> #should:notTakeMoreThanMilliseconds: TestMatcher >> #runWithin: Thanks, have now my own subclass which does
runCase self should: [super runCase] notTakeMoreThan: self expectedMaxRuntime And it works fine :) Best Stefan
If you dont use akuhn/SUnit the first two methods are in TestCase and the third requires Phexample.
cheers, AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
participants (6)
-
Adrian Kuhn -
Lukas Renggli -
Marcus Denker -
Mariano Martinez Peck -
Stefan Marr -
Stéphane Ducasse