GUI output testing

Richard A. O'Keefe ok at cs.otago.ac.nz
Fri Aug 8 03:25:31 UTC 2003


Colin Putney <cputney at wiresong.ca> wrote:
	My point is that doing a diff, whether textual or object oriented, will 
	be fragile. All it can tell you is that something has changed. If 
	you're running a unit test, you already know that.

With respect, this is either untrue or misleading.

You know the *code* has changed.

What you do NOT know is whether the *relevant aspects* of the morph tree
have changed.  The whole point is that you *don't* know whether it has
changed, nor, if it has, which relevant aspects have changed.

	You want to know if your UI still works correctly after the
	change, for some definition of "correctly."  Unit tests provide
	that definition.
	
You write as if (a) "Unit tests" and (b) starting from a known state,
playing back a recorded series of events, dumping selected aspects of
a morph tree as a file, and comparing that file with an earlier version
were two unrelated and even antagonistic things.  They aren't.  On the
contrary, (b) is a special case of (a).  Dumping and diffing isn't an
*alternative* to unit testing, it is a *kind of* unit test.

It's like telling someone "throw that wine away; you should be drinking
something instead."  There may be better things to drink than wine; there
may be better kinds of unit testing for GUIs than dumping and diffing,

My point of view is that dumping and diffing is something one can easily
do without knowing much about Morphic (which is the position I find myself
in), and that it not only isn't a rival to having other kinds of unit test,
a couple of rounds of dumping and diffing is one way to get ideas for more
focussed test cases.  Above all, it's a way of noticing things that you
_haven't_ written explicit test cases for yet.



More information about the Squeak-dev mailing list