This is the mail archive of the
mailing list for the Mauve project.
Re: Tweaking default java.awt.Robot settings
Steve McKayâ wrote:
If Robot can't be counted on to do something within some time
delay, is it also useless in non-test applications?
David's suggestion to use multi-threaded paradigms for dealing with
the issue seems pretty good to me.
Yes, I shouldn't have said useless.. maybe "hard to use" :-) In Mauve we traded
timing-independent reproducibility for test case simplicity. I did try writing
synchronized Robot-using tests but it was a) difficult, and b) invasive, in that
it required overriding and modifying the behaviour of methods that were being
For example, we can block until a
window is ready to process events with code like this (only half baked
at this time):
Even after you've ensured that the frame has responded, subsequent checks will
still need to be synchronized, since Robot calls are not synchronous. Or is
this the specific problem that was causing test failures for you before -- that
frames take a long time to be ready to receive events on other runtimes (e.g.
Wine)? If that's the main problem then maybe a hybrid approach of synchronizing
frame readiness, then assuming small delays for Robot method calls, is a better
approach. Otherwise the proposal is to rewrite every Robot-using test to be
perfectly synchronous (fine by me, but a big job).