Swing Extreme Testing - The wasCancelled() Test

The wasCancelled() Test

The first of our API tests is to check the wasCancelled() method. We will basically do three investigations. The first test will call wasCancelled()before the dialog has been cancelled. The second test will cancel the dialog and then call the method. In the third test we will enter a name, cancel the dialog, and then call wasCancelled().

There will be a subtlety in the test relating to the way that the Cancel button operates. The button is created in the constructor of the SaveAsDialog:

The action associated with the button sets the wasCancelledinstance variable of the SaveAsDialog. The wasCancelled() method simply returns this variable:

From SaveAsDialog
public boolean wasCancelled() {
return wasCancelled;
}

It follows that the wasCancelled() method is not thread-safe because the value it returns is set in the event thread. Therefore, in our test, we need to call this method from the event thread. To do this, we put a helper method into our test class:

Our wasCancelledTest() then is:

There are three code blocks in the test, corresponding to the cases discussed above, with each block of code being very simple and making use of the wasCancelled() helper method.

Writing code like the wasCancelled() method is pretty tiresome but is essential for solid tests. In fact, it's so important and so easily overlooked that we include it as a guideline:

NOTE: Extreme Testing Guideline: Any variable in a user interface or handler that is set from the event thread needs to be read in a thread-safe manner.

Non-adherence to this guideline was the problem with our LoginScreenTestin Chapter 7. We checked the username and password passed back to the handler when Ok was pressed, but did not take care to do this safely, thereby guaranteeing intermittent test failures.