testing morphs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

testing morphs

Tudor Girba
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
Reply | Threaded
Open this post in threaded view
|

Re: testing morphs

Martin McClure-2
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
Reply | Threaded
Open this post in threaded view
|

Re: testing morphs

Tudor Girba
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
Reply | Threaded
Open this post in threaded view
|

Re: testing morphs

Martin McClure-2
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
Reply | Threaded
Open this post in threaded view
|

Re: testing morphs

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