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

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine