On Thursday, August 7, 2003, at 08:25  PM, Richard A. O'Keefe wrote:

> 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.

True. I stand corrected.

> 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.

I agree. My contention is that the simplest and most effective way to 
determine whether the morph tree has changed, and if so, whether the 
change is relevant, is to examine the morph tree.

> 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.

Yes, I see that. I'm not trying to put  (b) in opposition with (a). I'm 
comparing (b) with (b'), also 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,

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."

<Richard sets off in the other direction>

Colin: "Hey Richard, aren't you thirsty?"

Richard: "Parched. See that ridge over there? I'm going to hike over it 
and dig a well on the other side. The ground is a bit softer there, and 
I've got this shovel, so it won't be too hard."

> 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.

Are you saying that you favour dumping and diffing because it lets you 
examine Morphic in terms of XML, which is easier to understand?

Here's my situation. I don't know much about Morphic either, which is 
why I'm interested in being able to write unit tests for Morphic 
models. They provide a safety net I really need when doing GUI work.

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.

Is it because you dismissed my suggestion without really considering 
it? Is it because you found some problem with it that I'm not aware of? 
Is it because you have a different goal than I do?

Colin