<br><font size=2 face="Courier">Hi Richard,</font>
<br>
<br><font size=2 face="Courier"> There are actually several commercial testing utilities for Windoze application development that can do automated GUI testing (one that comes to mind is Vermont HighTest). A technician in my old department at work (this was several years ago) used it to test a VisualBasic GUI we made for one of our call controllers. It had a feature where it could test different screen regions, windows, or controls for changes and could compare against expected results.</font>
<br>
<br><font size=2 face="Courier"> I wouldn't suggest that automated GUI (even graphical output testing) is trivial, but it is possible and there are commercial examples out there. It can also be done without having a person in the loop for regression testing.</font>
<br>
<br><font size=2 face="Courier"> -Dean</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Richard A. O'Keefe" <ok@cs.otago.ac.nz></b></font>
<br><font size=1 face="sans-serif">Sent by: squeak-dev-bounces@lists.squeakfoundation.org</font>
<p><font size=1 face="sans-serif">08/05/03 08:03 PM</font>
<br><font size=1 face="sans-serif">Please respond to The general-purpose Squeak developers list </font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: squeak-dev@lists.squeakfoundation.org</font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: Re: GUI output testing</font></table>
<br>
<br>
<br><font size=2 face="Courier New">Julian Fitzell <julian@beta4.com> replied.<br>
His reply included:<br>
There can still be problems of course but I think you're going<br>
to need a human at the end anyway.<br>
<br>
That's really the issue. How often do you need that human, for how long,<br>
and doing what?<br>
<br>
Event record/playback means that we can handle the input side of a GUI<br>
test case without inflicting RSI on too many people.<br>
<br>
For usability tests, you need a handful of users trying to solve some<br>
real(istic) problems. But when you are doing regression testing, you<br>
might want to have the visual output checked, again, and again, and<br>
again.<br>
<br>
In the case of Morphic, it's easy to see how you could easily add<br>
some kind of #dumpXmlOutlineOn: aStream message to Morphs which would<br>
store say morph type, bounding box, foreground and background colour,<br>
and children, with morphs that hold values dumping their value as well.<br>
That way you could periodically save outline snapshots, and then compare<br>
them with expected snapshot. This wouldn't be as good as having someone<br>
look at it, but you could check what data had changed and whether things<br>
overlapped that shouldn't and so on. And you could do it *without*<br>
modifying the application logic, which is a plus.<br>
<br>
The student in question was telling me about a commercial project he'd<br>
worked on where their testers spent *hundreds* of hours starting at<br>
screens, and he was concerned that (a) this wasn't a very nice thing<br>
to do to people and (b) it wasn't all that effective at QA anyway.<br>
(Of course the project didn't use Squeak or any other Smalltalk.)<br>
He wanted to know if there was anything better, and I thought that if<br>
there was, some Squeaker would be sure to know.<br>
<br>
<br>
</font>
<br>
<br>