This is the mail archive of the mauve-discuss@sourceware.org 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


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?

Tom



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:
http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications
of GUI testing methods.. it's been added to over several years and has some good pointers.



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