Richard A. O'Keefe wrote:
> I've just been asked this question by a student,
> and I didn't really know the answer.
> 
> "How do you test the (visual) output of a GUI program?"
> 
> I suggested all sorts of things, from grabbing a Form and comparing it
> with a stored Form to saving the Morph to a file and comparing the files,
> but it all seems a bit vulnerable (user changes round/square corners
> preference => all comparisons fail).
> 
> Is there a way of testing the visual output of a GUI program
> that doesn't involve handcuffing a user to the desk to look?
> 

I'm sure Colin will reply as soon as he gets up tomorrow, so I won't go 
into the details, but he did a presentation at Smalltalk Solutions about 
this sort of thing.  He was mainly focused on testing web interfaces but 
the general principles are applicable to other GUIs as well.  What his 
system does it make assertions saying specific pieces of data are on the 
page, that there are links (or buttons, or whatever) that go to specific 
places, etc.  So you can define the functional features that your GUI 
needs without specifying it pixel  by pixel (which as you mention is 
ridiculously fragile).

There can still be problems of course but I think you're going to need a 
human at the end anyway.  Most manufacturing processes have all kinds of 
machine specifications and mesaurements and checks, but at the end 
there's almost always a human doing a final inspection.

Anyway, I'm sure Colin will jump in with more detail on the pros and 
cons of various ways he's looked at doing this.  I'll go off to bed now :)

Julian