From: Phlip <pplumlee@...>
Date: 2001-11-01T14:58:04+09:00
Subject: [ruby-talk:24054] Re: Anybody got any experience with automated unit tests for RubyTk GUIs?

Armin Roehrl wrote:
> 
> Hi all,
> 
>         anybody here having any experience with unit
> tests for RubyTk GUIs?
> 
> Maybe even a small code-snipplet to share?
> 
> Automatic testing of GUIs is always tricky, but
> maybe s.b. got some good tricks here.

Some GUIs make testing a pain in the 'nads. For example, MS Windows may
do some things before the first WM_PAINT message dispatches, but some
libraries may trigger important events inside that WM_PAINT call. So you
must display the window and crank its bogus input event queue just to
get behavour out of it.

Tk is a breeze. You can even paint a Canvas and then query back the
attributes of the objects in it, all before calling mainloop.

Then, don't call mainloop.

Set a global variable to true if you want to see & manually test your
UI, false if you don't or if the test is part of a batch. Assuming "top"
is your Toplevel window, test this variable and either call
root.mainloop or root.destroy. Your arena should be clean and ready for
the next test.

In some situations your arena may not now be clean. Destroying a window
sometimes leaves, say, the Image library in a different state than
clicking its close box would have. Deal with these problems with
individual hits to Google Groups.

I don't know how to simulate keystrokes or mousestrokes, but I don't
worry about testing library code and I just call the same callback as
the input event should have called.

Caveat: I know all this from testing the snot out of Python's Tkinter at
work. But any difference between that and RubyTk would really surprise
me.

CodeUnitTestFirst is a Silver Bullet that will kill many slavering
lycanthropes; the more you practice it the faster your career will go.
Rock on, holmes!

-- 
Phlip

http://www.greencheese.org/MakeItSo