How do you write test suites for GUI components?

[j_mckitrick]

What exactly do you test for?

 

[Marcus von Appen]

What exactly do you test for?

What GUI is exactly discussed here? A specific toolkit? Writing an own
GUI render engine and components?

I am currently writing an own GUI toolkit based on pygame (located at
http://ocemp.sf.net) and my major approach for testing the components will
be the following:

* Testing object instantiation and addition to the render engine
* Testing all public and private methods using various parameters
* Testing the behaviour of the object after modifying (public) attributes
* Testing the event management of the object
* Testing the container behaviour (packed widgets in tables, Frames, etc.)
* Testing collision detection of objects (if wanted)
* Testing the removal of the widget (correct unregistering any events,
deletion of all references, etc.)
* Testing exception handling, if any
* Testing threading behaviour, if any
* Testing the object behaviour, when the renderer attributes (, etc.) change

Though I did not implement any test stuff for my current engine and
componenets I would (and will) always go that way.
I also would place the test framework either in the corresponding module
or into an own module (dependant on the implementation of the toolkit).

Regards
Marcus

 

[David Bolen]

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

 

[j_mckitrick]

I guess mine will be much simpler, then.

I have pygtk guis tha are the interface to my application. If test
suites are so important, how can they be applied to modules that just
run dialogs or windows?

 

[Peter Hansen]

What exactly do you test for?

http://c2.com/cgi/wiki?TestFirstUserInterfaces might have some
interesting answers for you.

-Peter

 

[David Bolen]

I guess mine will be much simpler, then.

I have pygtk guis tha are the interface to my application. If test
suites are so important, how can they be applied to modules that just
run dialogs or windows?

When testing a GUI, IMHO what you are testing is that actions taken
against that GUI turn into appropriate operations on your underlying
application data model, as well as that the appropriate portion of
your data model is going to be reflected in the presentation of the
GUI.

So, do those dialogs or windows interact with your business logic?
That is, when a user manipulates controls on those dialogs or windows,
what sort of actions are taken on the data managed by the application.
That's what you want to test is occurring properly.

Or, do those dialogs or windows display data that is obtained from
your business logic? That's what you want to test will be displayed
properly.

By separating out the act of translating actions on a GUI control into
business logic actions, versus the management of any data that
underlies a GUI control (the text for a static text box, or the label
on a button), versus the drawing of the control itself and interaction
with external events like mouse presses, you can go a long way towards
testing a lot of how the GUI operates. Combine that with tests to
ensure that your business layer operates properly (sans GUI), and
you've got some reasonable coverage.

-- David