May 01, 2001, 7:46 PM —
In the first installment of this series, we outlined what it means to test graphical user interface (GUI) applications, and to what ends that testing is done. (See part 1.) Now we'll apply those abstractions to a model situation that illustrates a handful of the best testing techniques specifically applicable to GUIs.
A sample program
The source code for this article is all written in Tcl/Tk. This is the one GUI binding most likely to be installed and already available on your workstation. There's a good chance you can enter the source code below and run it immediately on your desktop.
# Program 0.
set last_push 0
pack [button .b -text "Push me" -command {
set current_push [clock seconds]
if $last_push {
.l configure -text \
"It has been [expr $current_push - $last_push]\
seconds since the last button push."
} else {
.l configure -text "That was the first button push."
}
set last_push $current_push
}] [label .l]
That is a tiny application with one button, and one textual display updated by the button. It's written in a rather Visual Basic (VB) style of Tcl/Tk.
The fundamental problem
Even a program this small and simple raises several deep questions for GUI verification. At the most fundamental level lies the mismatch between the natural human expressions for useful tests, in terms of widgets and displays, and the computer's pixel orientation. The most important natural test of the application is one that validates the value of the display. However, as noted in the first installment in this series, there's no direct way to capture that information from an executing GUI application. Operating system access is in terms of pixels; translating a pixel display into a string -- like "11 seconds" -- is a surprisingly difficult problem. That's one reason we often choose clock- or calendar-related examples: they present interesting testing challenges in just a few lines of code. An inspection of commercially available products reveals how many of them mishandle even simple time-dependent displays and calculations.
One solution to the problem is to do "null comparisons": define a specific sequence of actions and check the precise pixel layout resulting from those actions. Judge the test successful if the layout corresponds exactly to a reference pixel display. Otherwise, fail the test.
That solution requires a separate test for each possible display. It offers no opportunity for parametrization, no recognition that the display with "13 seconds" might be in a sequence with a display for "14 seconds." Moreover, the strategy is sensitive to display details. A change in font, or screen resolution, or even smaller matters, causes tests to fail.
That strategy is, however, generally adopted by commercial record-and-replay products. Later we'll look at ways to make the strategy viable.
Our preference in most cases is to introduce a "testability layer" in the design of the GUI application. We're going to reduce our testing problems to separate the GUI from the textual parts. We'll make the GUI elements very simple, so simple that they can be designed correctly and validated easily "by hand." The full power of "classical" command-line testing verifies the textual parts.
Separating computation from the interface
Working code examples make this clear. Rather than Program 0, above, consider
# Program 1.
# Notice that this procedure has no GUI
# elements.
proc get_text_for_label {} {
set current_push [clock seconds]
if [info exists ::last_push] {
set result
"It has been [expr $current_push - $::last_push]\
seconds since the last button push."
} else {
set result "That was the first button push."
}
set ::last_push $current_push
return $result
}
# This procedure acts purely on the label.
# It is independent of the button.
proc set_label {} {
.l configure -text [get_text_for_label]
}
label .l
button .b -text "Push me" -command set_label
pack .b .l
