Colin Putney <cputney at wiresong.ca> wrote:
	Yes, I can see how that would be a frustrating thing to hear. From my 
	point of view the conversation has gone more like this:
	
	Richard: "Gosh, I'm thirsty."
	
	Colin: "Yeah, it's hot. But there's a well right over there. Here's a 
	bucket."
	
Now this is where he parted company with reality.
Because he hasn't, NOT ONCE, told me anything I can actually DO
to test a GUI.  "Use unit tests", well, that's what I *want* to do.
"Examine the morph tree", well that's what I *am* doing.

I have already explained the basic problem with examining
the morph tree by firing messages at it in general:

    "Ugh, it's ALIVE."

(a) A morph tree is not a collection of passive data structures.
    (Unlike an XML document.)  It's a collection of *active* *animated*
    objects which can do all sorts of things while you are trying to
    probe it.

(b) If you want to compare before/after views, then you are utterly and
    totally sunk, because you don't *have* the before view any more,
    unless you have saved it in some form (such as an XML document).

	Are you saying that you favour dumping and diffing because it lets you 
	examine Morphic in terms of XML, which is easier to understand?
	
This interpretation is sufficiently far askew of what I actually wrote
that I'm a bit puzzled how to answer it.  I make no claim about whether
XML is *in general* easier to understand than Morphic, only that I *do*
understand it far more than I understand Morphic.  But even that isn't
my point.  My point is that a "dead" data structure like an XML document
is easier to *process* with simple tools than an "active" collection of
"live" objects like a morph tree.  I can be quite sure that any probes I
make into an XML document do not affect the morph tree at all, and in
particular, do not affect it in any way that might invalidate other queries.

There is also the rather important point that dumping and diffing lets
me notice potentially important changes in morphs WHOSE VERY EXISTENCE
I HAD NEVER PREVIOUSLY SUSPECTED.  This has actually *happened*.  I quite
literally could not have written tests for Morphs I not only didn't know
would be in the tree but had never suspected existed at all.  But by
dumping and diffing I *can* discover changes in them.

The fact that XML is involved really isn't relevant (except to the degree
that it makes XPath available for queries and an XML-aware database available
for storing snapshots reasonably compactly).  As I've remarked before,
OIF would do quite as well, if I understood OIF well enough to write an
OIF writer.  YAML would be perfectly splendid for the job.  Joe Armstrong's
UBF would probably do, except that it's not really meant as a "text" format.
It doesn't even really matter all that much that it's a text-based format;
storing a morph tree as an ImageSegment would probably do.  What DOES matter
is that there is some method available (which I didn't have to program) for
comparing two dumps and reporting any differences in human-readable terms.

By the way, it case it wasn't clear, I was *praising* Smalltalk and Morphic
for making it so very easy to develop such a tool.

	I've found a method that seems to work fairly well, but I don't have 
	enough experience with it to know what the pitfalls might be. I'm 
	genuinely interested in what others think about it, and in other 
	methods for doing the same thing.
	
	You've expressed interest in unit testing GUIs, but no interest in the 
	method I suggested. Instead you're pursuing a strategy that appears to 
	me to be more difficult and less rewarding that what I'm doing. I'm 
	trying to understand why that is.
	
To start with, what I have described took 2 hours to implement and only
seconds to apply.  Where you get the idea that it's "difficult" is beyond
me.  As for "rewarding", in building and using this tool, even in its
present rather limited state, I have learned quite a lot.  As a specific
example, I have learned that #defaultColor does NOT mean what I thought
(from reading some of the Morphic source code) it meant, and that's actually
quite a big reward.

That doesn't mean it's better than whatever it is you do.
However, despite reading all of your messages in this thread that
have actually reached my maine, I still haven't the faintest idea
what your method actually IS, other than "do unit tests" by probing
the morph tree as it stands (with all the pitfalls of doing that).

For what it's worth, I've recently learned about a promising method,
which does sound like a fair bit of work, and that's the use of "Mock"
objects.  I've read about it in the "Naked Objects" book, and I've read
about it in an XP web site.  The idea is that each of the graphic classes
you normally deal with is replaced by a "Mock" version which doesn't
actually draw anything, and doesn't respond to real keystrokes or mouse
clicks, but does hold the information you would want displayed, and can
simulate (to some extent) user interface actions.	

It will be a long time before I feel confident enough to try that,
especially as the Naked Objects book is in hot demand so I had to return
it to the library before finishing it.

What's interesting here is that the Mock objects approach is again
based on *not* messing around with real graphic objects, but with something
which basically records their information content.