This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tweaking default java.awt.Robot settings

Steve McKayâ wrote:
Hi Thomas,

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]