Hi,
I would like to test the code related to rendering a morphic interface. In particular, I would like to test the rendering of Glamour browsers with morphic. The problem is that the rendering happens in another process than my regular test code. Any idea of how I could solve this problem? Cheers, Doru -- www.tudorgirba.com "Don't give to get. Just give." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Tudor Girba wrote:
> Hi, > > I would like to test the code related to rendering a morphic > interface. In particular, I would like to test the rendering of > Glamour browsers with morphic. > > The problem is that the rendering happens in another process than my > regular test code. Any idea of how I could solve this problem? > I'm not sure I understand exactly what you're wanting, but maybe you do some action in your main test code, this causes some rendering to happen in another thread, then after some unknown amount of time that thread finishes rendering and comes to rest, and you want to test whether the final state is what you expect? In that case the real problem is knowing when to expect the final state to be final. One pattern we've used for UI testing is to have a method in the test class waitUntil: conditionBlock You give this method a block that tests the condition and answers true if all is good. The method runs the block every 20ms, using a Delay between to allow the other thread(s) to run. As soon as the condition is true, it returns. If five seconds pass without the condition ever becoming true, it reports a test failure. This lets you test the results of a unit of work in another thread without slowing your tests with worst-case delays. Regards, -Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi Martin,
>> I would like to test the code related to rendering a morphic >> interface. In particular, I would like to test the rendering of >> Glamour browsers with morphic. >> >> The problem is that the rendering happens in another process than my >> regular test code. Any idea of how I could solve this problem? >> > > I'm not sure I understand exactly what you're wanting, but maybe you > do > some action in your main test code, this causes some rendering to > happen > in another thread, then after some unknown amount of time that thread > finishes rendering and comes to rest, and you want to test whether the > final state is what you expect? Indeed, this is what I want. > In that case the real problem is knowing when to expect the final > state > to be final. > One pattern we've used for UI testing is to have a method in the > test class > > waitUntil: conditionBlock > > You give this method a block that tests the condition and answers true > if all is good. The method runs the block every 20ms, using a Delay > between to allow the other thread(s) to run. As soon as the > condition is > true, it returns. If five seconds pass without the condition ever > becoming true, it reports a test failure. This lets you test the > results > of a unit of work in another thread without slowing your tests with > worst-case delays. This sounds interesting. Would it be possible to get a code sample (in particular of the waitUntil: method)? Cheers, Doru > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "What is more important: To be happy, or to make happy?" _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Tudor Girba wrote:
> > This sounds interesting. Would it be possible to get a code sample (in > particular of the waitUntil: method)? > Sure. Here's the code we use in VW. I clearly didn't remember exactly what we called it. :-) We have a number of simpler methods that use this one, which is the most general case. Once you account for GemStone and VW-specific stuff, I imagine this approach should work in Pharo. Regards, -Martin gbtPauseUntil: validateBlock evaluatesReturning: expectedResult maxWaitSeconds: maxWaitSeconds "Evaluate validateBlock until it returns expectedResult or maxWaitSeconds have passed, pausing between evaluations. Return the last result of validateBlock value" | startTime result | startTime := Time secondClock. [result := validateBlock value = expectedResult] whileFalse: [Time secondClock - startTime > maxWaitSeconds ifTrue: [^result]. (GbxDelay forMilliseconds: 50) wait]. ^result _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Thanks Martin!
Cheers, Doru On 13 Nov 2009, at 03:11, Martin McClure wrote: > Tudor Girba wrote: > >> >> This sounds interesting. Would it be possible to get a code sample >> (in >> particular of the waitUntil: method)? >> > > Sure. Here's the code we use in VW. I clearly didn't remember exactly > what we called it. :-) > We have a number of simpler methods that use this one, which is the > most > general case. Once you account for GemStone and VW-specific stuff, I > imagine this approach should work in Pharo. > > Regards, > > -Martin > > > gbtPauseUntil: validateBlock evaluatesReturning: expectedResult > maxWaitSeconds: maxWaitSeconds > "Evaluate validateBlock until it returns expectedResult or > maxWaitSeconds have passed, > pausing between evaluations. Return the last result of > validateBlock > value" > > | startTime result | > startTime := Time secondClock. > [result := validateBlock value = expectedResult] whileFalse: > [Time secondClock - startTime > maxWaitSeconds ifTrue: [^result]. > (GbxDelay forMilliseconds: 50) wait]. > ^result > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |