Featured White Papers

Free Trial Download: Build Professional Java Installers with InstallAnywhere

Automate GUI tests for Swing applications

Transition from unit tests to acceptance tests

By Ichiro Suzuki, JavaWorld.com, 11/15/04

Print
Email
Feedback
Resources
Discuss

Digg
Reddit
SlashDot
Stumble
del.icio.us
Technorati
dzone

Over the last two years, I spent some time developing a GUI application using Java Swing. The application was small, consisting of several classes in the MVC (Model-View-Controller) model, but was moderately complicated, having many external components with which to communicate. To avoid total confusion, my team applied extreme programming (XP) methods, which emphasize testing, as much as we could to the project. But we encountered technical problems testing the view part: how would we perform unit tests and automate acceptance tests?

Test-driven development, with unit tests, has always been easy and straightforward using JUnit driven by Ant. We started having difficulties with our project when we began developing the view component and testing it. We were unaware of a good technical option for unit-testing GUI components.

On the other hand, an acceptance test is a less formalized process than a unit test in terms of tools for automating it. Sometimes, human testers perform acceptance tests to check the application's behavior as a whole. But, for a GUI application, how the application responds to human operations is equally important as its underlying functioning. We like to run acceptance tests frequently during development. Therefore, automated and comprehensive acceptance tests proved important.

We started with simple unit tests that solved some of our technical problems. To automate our acceptance tests, we applied the same techniques used in the unit tests to the application's acceptance tests (or story tests). We were then able to write tests easily and run them frequently, which is essential for XP.

Sample application

Let me explain what my team learned using a simple application, shown in Figure 1.

Figure 1. Sample Swing application

The application has a text field. When a string is typed, it adds ? to the end. When the Doit! button is clicked, a dialog box displays the text—see Figure 2.

Figure 2. Modal dialog box when the button is clicked

The application also has a menu for changing the text color (Figure 3).

Figure 3. Menu items to change the input field text color

Of course, according to XP's "test-first" rule, application code should not exist prior to the test code. But for this article's purpose, we start from this completed code and focus on the test code.

Access Swing components from test code

First, we define the problem. Our aim is to automate acceptance tests, namely to test the code of our application, and type its strings and click its buttons. Our application uses Swing components, and JUnit is our testing framework. In generic terms, our aims can be written as "Using JUnit, test code can access an application's Swing component" and "Test code can change and retrieve a component's states." The latter is easy once we get an instance of the component.

There are many ways to access Swing components:

Application code has getXxx() methods to return each component of interest.
Test code invokes events on a screen, mimicking a human operator. Events are typically mouse moves/clicks and key typing.
Test code traverses the component tree and finds a component of a specific signature (class, location, order, text contents, etc.).

When choosing a method, two factors are important. One is simplicity and the other is independence between application and test code.