Al Williams

Dr. Dobb's Bloggers

Things That Go Boom

December 24, 2014

It is easier to make a safe light bulb than to make a safe explosive.

A colleague told me the other day he didn't want his system to "go boom." I laughed and noted that many of the systems I've worked on over my career are supposed to go boom. You just want don't want them to go boom at the wrong time.

I think that makes things a little harder. It is easier to make a safe light bulb than to make a safe explosive. The explosive is supposed to be dangerous. So while testing is important across the board, it is especially important when you have systems that can cause significant injury or property loss.

Up until fairly recently, the kinds of things I built — especially the dangerous ones — rarely had GUIs in the traditional sense of the word. It was pretty easy to create test drivers that would exercise the system so you could simplify a large number of comprehensive tests. When you start throwing GUIs into the mix, that gets a little harder.

What you really need to produce those kind of tests (and, possibly, scripting for end users) is a way to fake keyboard and mouse events into the system. Usually, how you do this is highly system-dependent. I talked about a Windows solution for this way back in the 1990s. There are other ways to accomplish the same task under Windows, and on Linux you might resort to xdotool or some similar tools. You could also insert input events into X or into the underlying system using lots of different methods.

If you are just interested in testing, though, you might also want a more universal solution that frees you from worrying about exactly how the job gets done. I have a love/hate relationship with Java, but I will confess this is one area where Java is a great choice. Assuming, of course, that you have Java available. But if you have a system big enough to have a GUI, I'm guessing you have (or can easily get) Java to run on it.

The secret is to use the robot feature of the old Java AWT (Abstract Windows Toolkit) library. Unless you are an old-school Java programmer, you probably haven't used AWT since most people now use Swing or some other GUI library. But the robot feature works even if you don't use the rest of AWT.

Using the Robot class is fairly simple. You need the import, of course:

import java.awt.Robot;

You also need to create a Robot object:

public class Action {
private static Robot robot;

You can use the object's delay method to pause for a given number of milliseconds, which is handy when dealing with keyboard and mouse handling. You can also use methods like mousePress, mouseMove, mouseWheel, keyPress, and keyRelease to simulate input events:

You might prefer to set an automatic delay time for every event by calling setAutoDelay. You can also wait for all events to finish by calling waitForIdle.

If you really want to get fancy, you can even ask the robot to read the pixel color at a given screen location or do a screen capture. This allows for some very sophisticated scripting, and since most embedded systems have a very fixed screen size and font selections, it might even be more reasonable to code a test like this than it would be on a desktop system.

I've posted to this blog for about 5 years and it is with a heavy heart that I close this, the final entry. As you probably know by now, Dr. Dobb's will be frozen in January and while the 25 years of articles and postings I've contributed will still live on, there won't be any more, which is very sad for me both as a long time writer and an even longer-time reader.

I wish I could thank everyone that I learned from at DDJ over the years, but there's simply too many. Like so many, I owe Jon Erickson pretty much everything having to do with my writing career. But I also learned a lot from countless other people associated with DDJ over the years. I also learned a lot by interacting with our readers by mail (back in the day), e-mail, and at conferences. Our readers tended to be a cut above (or, maybe, several cuts above) and I was never above asking a job applicant if they read DDJ.

Perhaps I'll reorganize my personal blog, which never really recovered from a failed hacking attempt, or add some new articles to my embedded site. Maybe I'll use the time to write some more books. Or perhaps I'll find a new writing home somewhere. But I can't imagine a new home that has the history, breadth, and technical weight of Dr. Dobb's Journal.

Thanks for letting me share my projects and ideas with you over the years. I hope to see you somewhere soon where hardcore technical discourse finds a home.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!