Debugging and testing Swing code

Swing is a powerful GUI toolkit that can be scaled, configurable, and Cross-platform. But Swing's flexibility is both a major advantage and a major weakness. Swing can build the same UI in different ways. For example, you can place an interval between GUI components using inserts, a blank border, or a fill. With too many Swing options, understanding the existing GUI is as daunting as writing a new GUI, and it's not easy to match its visual appearance to the underlying code. (Try thinking about the GUI when you read several code lines that use GridBagLayout.) ）

Whether you're maintaining a previously written Swing GUI or integrating Third-party GUI components into your application, a logical way to understand your code is to write tests. You are familiar with the internal construction of unknown code while writing tests. Doing so will produce another valuable result, which is that you end up with a test suite that helps prevent the introduction of regressions while maintaining the code. For Third-party GUI components, the test suite helps to find out whether any behavioral changes have been introduced into the new version of the library.

It's a good idea to write a functional test first to see how the GUI responds to user input. Writing tests for the GUI is more complicated than writing tests for non-visual code, because:

In theory, tests must be automated, but the GUI is for humans-not computer programs-to use.

Traditional unit tests involve testing of isolation classes and are not suitable for GUI components. In GUI terminology, a "unit" involves the collaboration of multiple GUI components, so it itself contains more than one class.

The GUI responds to user-generated events. To test the GUI, you need a way to simulate user input, wait until the generated events are disseminated to all listeners, and then examine the results, just as the GUI responds to the user. Writing code that simulates user interaction with the GUI can be cumbersome and error-prone.

Changing the layout of the GUI should not affect robust functional testing.

Another problem is that you have to familiarize yourself with the structure and behavior of the GUI you want to test, or you don't know which components to use for automated testing, and what needs to be validated. To summarize, to write a GUI test, you must know:

Components used in the GUI for testing

How to uniquely identify such a component in a test

Expected state (or property) of a component in a particular use case

Using visual design tools, such as NetBeans Matisse, you can figure out the structure of the GUI. However, this tool only displays design-time information for the GUI, which is different from what you see at run time. For example, some components may appear to be visible or invisible depending on user input.

Traditional debuggers do not help you understand the state of a GUI when executing a particular use case. When the debugger stops the breakpoint placed in Swing code, the GUI drawing is interrupted, making the GUI look like a blank box. Ideally, you want to see how the GUI works when you use the debugger for Single-step debugging.

Fortunately, two open source tools-swing Explorer and fest-swing-can help you quickly understand the existing Swing code. This article introduces you to these tools and shows you how to use them together to examine the GUI structure of your application, test its functionality, and identify potential problems.

The application to explore

For most examples of the article, I'll use a free functional HTML editor called Htmldocumenteditor as the application to test. If you want to complete the sample yourself, you can download the application and sample test code. Figure 1 shows the Htmldocumenteditor in operation:

Figure 1. HTML Editor