Re: [lmi] Automated GUI testing

[Greg Chicares]

On 2005-11-17 23:57 UTC, Vadim Zeitlin wrote:
> On Thu, 17 Nov 2005 04:58:43 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC>     // Call the EVT_UPDATE_UI handler explicitly and retest.
> GC>     mvc.OnUpdateGUI(update);
> GC> 
> GC> This does work, at least as far as I can determine. But it doesn't
> GC> seem ideal.
> 
>  No, it would be better to send a wxIdleEvent. This wold automatically
> generate wxUpdateUIEvent as well and might do other (possibly critical)
> things too. Many things, especially but not only in custom controls, risk
> to break if idle events are not sent.
> 
> GC> I'm thinking of having OnUpdateGUI() raise a semaphore on entry, and
> GC> clear it only when it knows that it has found a fixed point. But
> GC> please let me know if you see a better way.
> 
>  A brute force solution would be to send a dozen of idle events, this
> should definitely be enough... A more intelligent one would be to modify wx
> itself to iterate in update UI event sending code until there are no more
> changes. I'm actually surprized we don't already do it like this...
> 
> GC> I will soon add tests that require generating some events, so a
> GC> general YieldToWxIdleProcessing() function will be needed in lmi.
> 
>  It should be (but this is untested) enough to just call
> wxTheApp->wxPostEvent(idleEvent).

I tried that in code committed a moment ago (20051119T1631Z):
  
http://savannah.nongnu.org/cgi-bin/viewcvs/lmi/skeleton/mvc_test.cpp?rev=1.3&content-type=text/vnd.viewcvs-markup
I still have to call the EVT_UPDATE_UI handler explicitly: idle processing
doesn't take care of that, even if I send 1000 idle events.

Is that because this unit test runs the dialog nonmodally?

If so, then I worry about this concern that you pointed out:

> Many things, especially but not only in custom controls, risk
> to break if idle events are not sent.

and that leads me to wonder whether running it nonmodally for testing
is a fundamentally unworkable idea.