This is the mail archive of the
mailing list for the Mauve project.
Re: Tweaking default java.awt.Robot settings
Thomas Fitzsimmons wrote:
David Herron wrote:
Steve McKayâ wrote:
Robot does not add events to EventQueue but it requests the OS to
synthesize an OS-level event.
How has Sun implemented GUI testing? When I was considering how to do
GUI testing in Mauve, I considered the EventQueue-posting approach,
but decided on a Robot-based approach instead. I thought Robot tests
would be more realistic, testing things like window manager
interactions and the native peers' event processing code. I knew
Robot tests would be more fragile, but I assumed that we could
compensate for the fragility: e.g. fix timing problems by introducing
delays, as Steve has proposed. Did Sun experiment with Robot tests,
then abandon them? If Robot can't be counted on to do something
within some time delay, is it also useless in non-test applications?
I've always wondered how the TCK certified AWT and Swing
functionality. Does it use EventQueue-posting?
We make heavy use of Robot.
I haven't been writing tests for a long time so I don't know for sure
the techniques used by the team. Sometimes I worry about whether they
are using sleep's and the like to synchronize validation that a desired
event has occurred.
If you click on something, move a mouse pointer, type a key.. there's a
listener fired in 99% of the cases you would be testing. So I think
it'd be more reliable to synchronize the validation based on when the
listener fires. Unfortunately that can turn into difficult coding to
ensure the test doesn't deadlock or otherwise go off into the weeds
because cross-thread notification of the listener firing didn't happen
in the right order. I'm sure it's much simpler to code up a simple
sleep and 99% of the time the system will be fast enough responding to
post the listener callback within a couple milliseconds.
I believe that the TCK, where it has automated tests, uses Robot as
well. I don't know that for sure since I've not been involved with
writing the TCK's, and that's a different team than mine. The TCK also
has manual tests.
And the reason you give for using Robot is exactly the reasoning we
have. Since we're testing AWT/Swing a we have to make sure to test AWT
and the peers. Stuffing events in the EventQueue doesn't test the
native parts of AWT including the peers. That was the rationale for
putting Robot into the platform in the first place (that and to support
writing freestanding demo apps), and it's true today.
- David Herron
P.S. there's a summary here:
of GUI testing methods.. it's been added to over several years and has
some good pointers.