Re: [lmi] Automated GUI testing

[Vadim Zeitlin]

On Thu, 17 Nov 2005 04:58:43 +0000 Greg Chicares <address@hidden> wrote:

GC> We've discussed automated GUI testing before, and now that I've
GC> put together a prototype, I think it can be much simpler for lmi
GC> than I had ever suspected.

 This is excellent news of course!

GC> First, the dialog has to be activated:
GC> 
GC>     // Use Show() instead of ShowModal() so that the dialog can be
GC>     // manipulated while it's shown.
GC> 
GC> A modal dialog would suspend the application's message loop, but
GC> here we need to keep control in the test routine, which I've set
GC> up as a friend of the dialog (actually, wxNotebook-derived) class.

 This is an interesting idea. I've originally thought of running the
testing code in a separate thread which would post the events to the main
thread queue (thus emulating user input) and, at least under Win32, could
be injected in the address space of another process. Or, if this were
discovered to be too complicated, execute the testing procedure from the
idle event handler.

 To be honest I still think that in general these solutions are preferable
but your approach is, of course, much simpler, so if it works for you...


GC> Show(false) demonstrably prevents the test from working, at least
GC> with msw.

 I could look into the details of why it doesn't work but this doesn't
surprize me at all. A hidden window/control may behave very differently
from a shown one and might not expect to receive any input at all.

 BTW, note that Show(false) is a NOP as the dialog is already hidden.

GC> Is there a simple way to make the test invisible?

 I could be wrong but I don't think so. I.e. even if we could make it work
now I wouldn't guarantee that it continues to work in the future when other
controls are added.


GC>     // WX !! There seems to be no way to do this by xrc name, e.g.
GC>     //   notebook.SetSelection(XRCID("ignore_panel"));
GC>     // But the pages could be enumerated and their names read.
GC>     notebook.SetSelection(0);
GC> 
GC> Has anyone ever considered implementing a function to select a
GC> wxNotebook tab based on the tab's (string) name? If not, then I
GC> understand that it's an exotic need; but I thought I'd ask before
GC> writing code to do it myself.

 I'm not aware of anything like this, sorry.


GC>     // Change control values, expecting the framework to react by
GC>     // enabling other controls.
GC>     check0.SetValue(true);
GC>     check1.SetValue(true);
GC>     // The framework reacts through its EVT_UPDATE_UI handler, which
...
GC>     // Call wxSafeYield() to see whether EVT_UPDATE_UI is handled.
GC>     wxSafeYield();
GC> 
GC> This doesn't work.

 There are probably no events in the queue so nothing is done by wxYield.

GC>     // Call wxSleep(1) to see whether EVT_UPDATE_UI is handled.
GC>     wxSleep(1);
GC> 
GC> This doesn't work, either. My guess is that it puts the whole
GC> application to sleep.

 Right. This doesn't dispatch any events at all.

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


 Regards,
VZ