I'll add my $.02 here.  I don't believe it's enough to test that certain
aspects appear somewhere within the GUI.  It's important that they
appear in the proper context.  In web pages you can assert that the
proper text/image/etc. appears in the correct cell of a table or that an
input field is in the right form, etc.

You can of course take this to ridiculous levels which would amount to
"pixel by pixel" testing, but that is overkill.  You should keep testing
until you are confident that the tests cover the gamut of things that
can break.  Once you have done that you may discover that there is
something else broken; so, write a test to verify the broken state of
the code and then fix the code until all of the tests pass.

=jason

On Tue, 2003-08-05 at 03:59, Julian Fitzell wrote:
> 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
> 
>