How do you write test suites for GUI components?

[David Bolen]

j_mckitrick at bigfoot.com (j_mckitrick) writes:

> What exactly do you test for?

As much as I possibly can :-)

With a GUI, I suspect there will always be a layer where the cost of
testing it is too expensive/resource intensive to make it worth while.
For example, do you test that the bitmap for the button appeared at
the right physical location within the window by bit-scraping the
window?  But the goal should always be to minimize the untestable
layer so it is as thin as possible, and thus as easy as possible to be
confident in without explicit automated testing (although you may have
some final human visual testing as part of an overall release).

In our development, that typically means using some variation of MVC
in developing the application.  You can then generally test the model
and controller portion fully and automatically, and the only remaining
piece is the pure display handled by your view in response to model
changes.  Depending on the presentation environment you may also be
able to automatically instantiate the view and simulate user actions
(whether programmatically or with a commercial automation tool) to
even test the linkage between view and controller/model, leaving just
the physical drawing/updating of the presentation not automatically
tested.

As a small example, one screen in an embedded product of ours has a
keypad that permits numeric entry of a 5 digit PIN.  That PIN is shown
on the screen as it is being entered/edited.  The code is structured
so that the string representing the PIN being constructed is a string
"model", which signals whenever it changes.  The logic for
manipulating the PIN (adding digits, clearing it out, etc...) exists
in a "controller" that has methods (or "slots" if you are using a
signal/slot mechanism) for each of its possible inputs - for our
keypad controller this is be digits 0-9, and Cancel.

So all of our automated test code instantiates the controller/model
pair (the construction of which is formalized in a single library
object), and then issues signals to the controller to simulate user
actions, and ensures that the model updates properly and that signals
emitted from the controller (when the PIN is complete) and model
(whenever it changes) occur properly.

All that's left for the production code is to have a view that
contains the necessary keypad buttons (which themselves emit a signal
when clicked), and route the signal from each keypad button to the
appropriate slot in the controller.  The view also has a text field
that is linked to the string model, and updates itself whenever the
model indicates that it has changed.  But other than presentation
logic to draw the buttons and entry field, the view has very little
code in it, and thus the portion of the system that is not
automatically tested is very small.

If your environment supports it, you can choose to automatically
instantiate such a view in tests, and then send simulated mouse events
to the appropriate buttons, thus ensuring that they are properly
linked to the controller and model.

http://www.c2.com/cgi/wiki?GuiTesting might also have some information
that is interesting.

-- David