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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Cool. I cc Adrian Kuhn that maybe he is interested.

Cheers

Mariano



_______________________________________________
Pharo-project mailing list
[hidden email]
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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Marcus:


On 22 Jan 2010, at 09:59, Marcus Denker wrote:

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


--
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli <renggli@...> writes:

 Please don't add this to TestCase. Sometimes I want to keep my
+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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

we should evaluate what adrian did and integrate it!

Stef

On Jan 23, 2010, at 1:03 AM, Adrian Kuhn wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi:

On 23 Jan 2010, at 01:03, Adrian Kuhn wrote:
Thanks, have now my own subclass which does

runCase
  self should: [super runCase] notTakeMoreThan: self expectedMaxRuntime

And it works fine :)


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


_______________________________________________
Pharo-project mailing list
[hidden email]
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



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 :)



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project