Automating UI tests (was Re: Art of Unit Testing)

Alex Martelli aleaxit at yahoo.com
Fri Aug 17 22:08:52 CEST 2001


"Joseph Andrew Knapka" <jknapka at earthlink.net> wrote in message
news:3B7D29E0.602AF8BD at earthlink.net...
    ...
> So that means I'd need to write code that actually drives
> the Tk widgets "from outside", as it were, either by synthesizing
> events somehow at the OS/window-system level, or by knowing
> enough about the Tk internals to convince the widgets that they're
> being clicked on, typed at, etc. And at that point it looks like
> a lot more effort than it's worth.

That's basically what we did at work for our capture-and-playback
based testing system -- knowing enough about the internals of
our own UI-engine architecture, of course (it's based on MFC, but
wraps it in a script-friendly way), so that events can be captured
and played back at different levels of abstraction (depending on
whether we're testing the UI-engine, or the actual application).

There are commercial solutions based on OS-level C&P, but of
course they're much more oriented to testing the 'externals' -- a
little change in UI layout or whatever, and your database of
captured sessions for regression-testing playbacks is toast.

I can't think of a reasonably complete solution that's worth the
effort for one user of a GUI toolkit -- the test-harness should,
it seems to me, be part of the GUI toolkit itself (alter sys.path
so a guitest directory is prepended, and rather than the actual
widgets &c what you're getting is some kind of test-harness
version).  But I don't know of any GUI kit, commercial or free,
for any language[s], that offers such a precious feature:-(.  It's
not easy to architect, of course:-(.


Alex






More information about the Python-list mailing list