On Sunday, August 10, 2003, at 04:32  PM, Richard A. O'Keefe wrote:

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

Hmm. Maybe you missed my first post in this thread. That would  
certainly explain our confusion:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-August/ 
064106.html

> I have already explained the basic problem with examining
> the morph tree by firing messages at it in general:
>
>     "Ugh, it's ALIVE."

As I mentioned in my first post, and have since reiterated, YOU DO NOT  
HAVE TO DISPLAY MORPHS WHILE TESTING THEM. As long as you don't add  
them to the World, they won't appear on screen and won't  respond to  
user input. You can *simulate* user input, but that's under the control  
of the test.

This seems to be the kernel of our miscommunication. I'll refrain from  
addressing the rest of your post until we can clear this up.

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

Going on the theory that you missed my first post, I've attached a file  
out of a test case I wrote for Monticello. It won't work in isolation  
as it relies on the rest of the package for setup, but reading the code  
should give you a better idea of what I'm talking about. If you want to  
actually play with it, install Monticello from SqueakMap.

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

Agreed. Mocks are a great way to test otherwise tricky bits of  
functionality. Actually, mocking out the Morphs was my first approach,  
and it was only later that I discovered it was totally unnecessary.  
Luckily I hadn't gone too far down that road, because Morphs do an  
amazing number of things, and recreating all that is a lot of work. The  
other advantage to using actual Morphs is that they interact with their  
model exactly as they would in the wild, so you can test the  
*behaviour* of the UI as well as it's appearance.

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

I've been playing with MorphicWrappers a bit - very cool stuff. I  
suppose I'll have to read Naked Objects too. One thing I like about the  
approach is that it forces you to keep your object model really clean -  
you can't paper over awkward protocols by putting a nice UI in front of  
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.

And this is the essence of your approach, I'm beginning to see. Given  
that you want to avoid real Morphs, I imagine this would be a *lot*  
more convenient than going outside the image.

That is the main problem I see with the XML approach. It makes actually  
running the tests more difficult than the one-click you need with  
SUnit. When I'm developing with unit tests, I like to get into a pretty  
fast rhythm of code-test-code-test. I'm running the tests every 15  
seconds or so. You could reduce the pain by running your XML tools with  
OSProcess, but even so it's probably not going to be that smooth.

Colin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: MCSnapshotBrowserTest.st.gz
Type: application/x-gzip
Size: 1981 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030810/652eb04d/MCSnapshotBrowserTest.st.bin