Home

Swing Extreme Testing

Author: Packt Publishing Published on: 10th Jul 2008

Swing Extreme Testing by Tim Lavers, Lindsay Peters

This book is a practical guide to automated software testing for extreme Java programming using Swing GUIs, with lots of ready-to-use real-life examples and source code for automated testing of the software components usually regarded as too hard to test automatically.

Read Sample Chapter 9 - Case Study: Testing a 'Save as' Dialog

This book is available for purchase at packtpub.com Swing Extreme Testing

Book Review : Swing Extreme Testing Book Review

Case Study: Testing a 'Save as' Dialog

In Chapter 7 we presented the idea of UI Wrappers for components as a way of safely and easily manipulating them in tests. In Chapter 8 we developed this further with specific techniques for reading the state of our user interfaces.

Ads

We will now draw these two strands together by studying in detail the test for an extremely simple user interface component. Although the component that we'll be testing in this chapter is simple, it will still allow us to introduce a few specific techniques for testing Swing user interfaces. It will also provide us with an excellent opportunity for showing the basic infrastructure that needs to be built into these kinds of tests.

In this chapter, we are taking a break from LabWizard and will use an example from our demonstration application, Ikon Do It. The code from this chapter is in the packages jet.ikonmakerand jet.ikonmaker.test.

The Ikon Do It 'Save as' Dialog

The 'Ikon Do It' application has a Save as function that allows the icon on which we are currently working to be saved with another name. Activating the Save as button displays a very simple dialog for entering the new name. The following fi gure shows the 'Ikon Do It' Save as dialog.

Not all values are allowed as possible new names. Certain characters (such as '*') are prohibited, as are names that are already used.

In order to make testing easy, we implemented the dialog as a public class called SaveAsDialog, rather than as an inner class of the main user interface component. We might normally balk at giving such a trivial component its own class, but it is easier to test when written this way and it makes a good example. Also, once a simple version of this dialog is working and tested, it is possible to think of enhancements that would definitely make it too complex to be an inner class. For example, there could be a small status area that explains why a name is not allowed (the current implementation just disables the Ok button when an illegal name is entered, which is not very user-friendly).

The API for SaveAsDialog is as follows. Names of icons are represented by IkonName instances. A SaveAsDialog is created with a list of existing IkonNames. It is shown with a show() method that blocks until either Ok or Cancel is activated. If Ok is pressed, the value entered can be retrieved using the name() method. Here then are the public methods:

Sample Code

public class SaveAsDialog {
public SaveAsDialog( JFrame owningFrame,
SortedSet<ikonname></ikonname> existingNames ) { ... }
/**
* Show the dialog, blocking until ok or cancel is activated.
*/
public void show() { ... }
/**
* The most recently entered name.
*/
public IkonName name() { ... }
/**
* Returns true if the dialog was cancelled.
*/
public boolean wasCancelled() { ... }
}

Note that SaveAsDialog does not extend JDialog or JFrame, but will use delegation like LoginScreen in Chapter 7. Also note that the constructor of SaveAsDialog does not have parameters that would couple it to the rest of the system. This means a handler interface as described in Chapter 6 is not required in order to make this simple class testable.

Ads

The main class uses SaveAsDialog as follows:

Sample Code