Chapter 23: Swing Testing with Jemmy

Overview

In the world of Swing GUI testing, Jemmy has a unique position. While, at a core level, it does the same thing that the other Swing testers do, it goes about it in a very atypical fashion. It isn't a JUnit extension. Its methods don't return values that can easily be put in an assert statement. And, at first, it seems like it had been written by aliens . But, once you get past the initial learning curve, Jemmy becomes one of the easiest swing testers to implement in Java code.

Where to Get Jemmy

Jemmy can be found at http://jemmy.netbeans.org/.

I highly recommend getting the source because the documentation is, well, not a bad reason to buy this book. Don't count on the Javadocs, either. I've found them to be missing, misleading, self-contradictory, and occasionally just plain wrong. The only drawback to Jemmy is that it lacks any method to automatically record tests by having it watch and remember your interactions with the Swing app you want to test.

 

It's a lot harder to make the case for Jemmy than it should be. Jemmy is a good choice when you want to write your test cases in Java. Once you get your head around Jemmy, you'll be able to write tests very quickly and with very little code. Sadly, Jemmy is not a good choice if you need to get your tests written yesterday . Or if you're not willing to have to occasionally poke through source code to figure out what it's doing, or why. It s not a good choice if you're looking for something that works like everything else, or gives you simple return values that you can stick into JUnit assert statements. In fact, at first glance, Jemmy seems like far more trouble than it's worth. But trust me, it can be worth it. Hopefully, this chapter will help to bring its worth to light, and minimize the need for any future code-poking.

When the NetBeans ( http://www.netbeans.org/ ) people decided that they needed a tool to test their Swing apps, they sat down and wrote Jemmy. Jemmy was not designed from the ground up to work with JUnit, but using Jemmy in JUnit isn't hard at all; it's just not what you d expect. Instead of testing the output of a method call against a known value, you simply execute the method. If it didn't work, Jemmy will throw an exception, which your TestCase will catch and record as a failed test, just as surely as a failed assertion would. There is no need to write explicit try/catch blocks to handle these exceptions.

The next departure from the norm is that you rarely deal directly with the Swing objects you're testing. Instead, you deal with Jemmy's Operator classes. For example, if you wanted to test if a button were functioning correctly, you would instantiate a JButtonOperator with some arguments to help it find the JButton you're interested in. The naming convention is pretty simple. It's the name of the class of the Swing object you're working with, followed by Operator .