Java - Debugging and testing Swing code

This is taken from "IBM DeveloperWorks"

When you need to use or maintain other Java™ developers' code, debugging and testing can help you understand how it works. In the case of visual code though, these powerful practices are more difficult unless you have the appropriate tools. The two open source tools that this article introduces — Swing Explorer and FEST-Swing — can make debugging and testing of Swing UIs simple and reliable.

Swing is one of the more powerful GUI toolkits available; it's extensible, configurable, and cross-platform. But Swing's flexibility is both its major strength and a great weakness. With Swing, you can construct the same UI in many different ways. For example, you can use insets, empty borders, or fillers to put space between GUI components. Given Swing's extensive stock of options, understanding an existing GUI can be as daunting a task as writing a new one, and mapping its visual appearance to the underlying code is far from trivial. (Try visualizing a GUI while reading a few lines of code that uses GridBagLayout.)

Whether you're maintaining Swing GUIs you didn't write or integrating third-party GUI components into your applications, a sensible approach to understand the code is to write tests. You explore the internals of the unknown code while writing the tests. As a valuable side effect, you end up with a test suite that can help prevent the introduction of regressions when you maintain the code. In the case of third-party GUI components, the test suite helps you find out if new a version of the library has introduced any behavioral changes.

 A good start is to write functional tests to understand how the GUI behaves in response to user input. Writing tests for GUIs is more complex than writing tests for non-visual code, because:
  • Ideally, tests must be automated, but GUIs are designed for humans — not computer programs — to use.
  • Conventional unit testing, involving tests of isolated classes, is unsuitable for GUI components. In GUI terms, a "unit" involves cooperation of more than one GUI component, which can itself consist of more than one class. 
  • GUIs respond to user-generated events. To test GUIs, you need a way to simulate user input, wait until the generated events have been broadcast to all listeners, and then check the result as the GUI would appear to the user. Writing code that simulates user interaction with GUIs can be tedious and error-prone. 
  • Changes in the GUI's layout should not affect robust functional tests.
An additional issue is that you must already know the structure and behavior of the GUI you want to test, otherwise you don't know which components the automated test should use and what needs to be verified. In general, to write a GUI test you must know:
  • The components that are present in the GUI to test
  • How you can uniquely identify such components in your tests
  • The expected state (or properties) of the components in a particular use case
You might be able to figure out a GUI's structure by using a visual design tool (such as NetBeans Matisse). But this type of tool shows only a GUI's design-time information, which can be different from what you see at run time. For example, some components may be made visible or invisible in response to user input.

Traditional debuggers cannot help you learn the state of a GUI while it's executing a particular use case. When the debugger stops at a breakpoint placed in Swing code, GUI painting is interrupted resulting in GUI that looks like a blank square. Ideally, you want to see how the GUI behaves while you step through it with a debugger.

Fortunately, two open source tools — Swing Explorer and FEST-Swing — can help you get up to speed quickly when you need to understand existing Swing code. This article introduces you to these tools, showing you how to use them in combination to inspect an application's GUI structure, test its functionality, and identify potential problems.

No comments:

Post a Comment