RFC: Mauve and java.awt.Robot?

[Norman Hendrich <hendrich at informatik dot uni-hamburg dot de>]

Hello everybody,

a simple and a not so simple RFC-type question about java.awt.Robot:


Mark> One of the reasons some of the non-gui stuff is in a much better shape
Mark> is because we have lots of small easy tests that we can run in Mauve.
Mark> For GNU Classpath releases we make sure that a new release doesn't fail
Mark> any of the tests that passed in the previous release. We don't have much
Mark> gui tests in mauve.

Mark>                           Thomas made java.awt.Robot working and there
Mark> are some examples on how to use this for automatic testing of the gui
Mark> components in Mauve.

(1) I just downloaded mauve-nightly.zip, but I cannot find any use of Robot
    in there... neither can grep. Where shall I look? Also, is there a
    snapshot of the Wonka tests, or do I have to do a full CVS checkout?


(2) Is there some kind of 'GNU policy' regarding the use of java.awt.Robot
    for automated GUI tests?  

    java.awt.Robot turns out a pretty dangerous animal, and I am not sure 
    that we would want to unleash Robot on unsuspecting users that simply
    type 'make check'.

Explanation:

For those who haven't played with java.awt.Robot yet: This class allows
exercising GUI applications by synthesizing *native* GUI events including
keystrokes, mouse movements, and mouse clicks. It will happily deliver
thousands of events per second to whatever screen position you specify,
and to whatever application happens to lie at that position.

This is fine as long as we can guarantee that those events are delivered
where we want them; however a single bad keystroke (like iconizing a
Frame via the users's WindowManager - ALT+something, META+something, etc)
might put an AWT Frame into the background and deliver those keystrokes
and mouse clicks to a wholly different application. Even worse, a single
minor fault in Window/Frame/Dialog might trigger this.


I ran into this problem when trying out an experimental class called
jfig.utils.Gremlins, based on java.awt.Robot and the 'gremlins' testing
approach. The basic idea (from PalmOS), is to use pseudo-random inputs
to simulate the average dummy user... Naturally, I made sure to deliver
events only to my app, and not outside its Frame.

On the fourth run, the random generator created a keystroke that was
intercepted by the window manager, which switched virtual desktops.
Robot continued to type random commands, but now into a root shell.
The AWT kept informing me that the screen position was inside the Frame;
and the keystroke in question was undocumented for the WindowManager.
On the plus side, I had a backup.

Naturally, using Robot in a controlled environment with carefully
prepared keystrokes and mouse movements is less dangerous, but I
wouldn't count out any suprises. If anything goes wrong, for example,
"[Startmenu] [Settings] [Control Panel]" is just three mouseclicks,
and from there the options for havoc multiply. (The same holds for
Linux control panels like YaST.)

- Norman