AWTomation Update

You may remember in a previous post, that I was looking at an automation system for an internal application.  Today I stumbled across the the Java robot class.  It is described in the help page as

This class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed.

So this seems like it might be a contender until I read this blog post.

We have found that this approach is dangerous.

  • Robot tests are very fragile, breaking any time the GUI layout changes.
  • If the user moves the mouse while the tests are running, the Robot continues clicking, sometimes on the wrong application.[11]

[11] One programmer reported that the Robot sent a partially completed email because it clicked on the send button of the mail client instead of a button in the application being tested.

  • Since the tests run so quickly, it can be impossible to stop the tests once the Robot gets confused and starts clicking on other apps and typing characters that show up in other windows.

If you really feel that you could use some Robot tests, consider naming them differently than other tests. You might have a collection of RobotTest*.java tests. You can then run them independently of other tests, if you are extremely careful to avoid touching the mouse while the tests run.

So based on that I think I’m going to stick with my reflection based library.

Mike is the programmer in the bunker. He writes software for a shaddowy software house in Worcester. He works mainly in .NET and python, but equally has found himself having to support different technologies such as MAXScript and .NET integration. Spending most of his time working on his passion of content packaging, and is currently working on an ebook authoring system for Ubuntu. Although he is the main programmer on the site he doesn’t do much with regard to writitng games