Mike Conigliaro

Thoughts on GUI Automation

Until today, I never thought much about writing scripts that rely on a GUI. I knew there were tools out there to do it, but I never looked into it, because it always seemed kind of tasteless to me; like something a VB programmer would do out of ignorance. And then when I did some research for a project I was working on today, I found confirmation of that in some hilarious quotes about one particular GUI scripting language being “the nicest procedural programming language I’ve [sic] ever worked with.” Obviously these people spend too much time dragging around windows and clicking on buttons to know what the hell they’re talking about, so before I go any further with this post, I’m going to give you a list of reasons why it’s generally not a good idea to write a script for a GUI:

  • It requires a GUI. That’s a lot of overhead for a script. So you either leave your computer logged in with some predetermined user account, or you somehow script the logon and logoff part too. Both methods are insecure and a waste of system resources.
  • It’s basically reverse “screen scraping,” and the same caveats apply. Your script is relying on display elements that are more or less guaranteed to change in the future (upgrades, etc.). That means your script will most likely have a very short lifespan, lots of updates, or both.
  • It’s an inefficient method of programming. A GUI is designed for interaction between a human and a computer; not between a computer and itself. All those mouse clicks are translated into machine instructions anyway, so if I already know the machine instructions I want to execute, why would I want to waste time telling the computer where to type text and click the mouse? A GUI script is working with an unnecessary layer of abstraction, which is only useful when building Rube Goldberg machines, and Rube Goldberg machines have no place in any IT department.

There are a few situations, however, where automating a GUI is a very good idea. The most obvious use for GUI automation is in unit testing and software quality control. Obviously, good unit tests are a lot cheaper and less error-prone than QA people, and from what I can tell, software developers are the target audience for most commercial GUI scripting tools.

Another good use for GUI automation (as I discovered today) is when working with shitty old software with proprietary databases of which there is no hope of accessing with Python. In my case, I had to come up with a way to pull a report out of the biometric security system for one of our datacenters and email it to someone on a weekly basis. My first thought was to connect directly to the database using the Python DBI and do the query myself, but gave up on that idea when I discovered that not only was everything written in German (the filenames, the documentation, everything), but the actual “database” was just a bunch of crusty old binary files.

The ultimate solution was a free scripting language called AutoIT. It isn’t exactly pretty, but it works. And seeing as how the GUI for our security system looks like something out of Windows 95, I figure I probably won’t have to worry about it changing my script any time soon.

blog comments powered by Disqus