"Daniel" <notdanielt3 / gte.net> wrote in message
news:151220011036049046%notdanielt3 / gte.net...
> Ron Jeffries <ronjeffries / REMOVEacm.org> wrote:
>
> >On Sat, 15 Dec 2001 05:28:53 GMT, "Daniel T." <notdanielt3 / gte.net>
> >wrote:
> >
> >>Unfortunatly, I write video games for 5 year olds for a living. The
only
> >>thing that's important is the GUI... Why test the stuff that doesn't
> >>matter?
> >
> >Possibly Daniel T overstates his case. Certainly GUIs are important
in
> >video games, and certainly they are hard to test.
>
> I may very well be overstating my case just to make a point. Isn't
that
> what makes newsgroups so lively? :-)
>
> >But I always hated it when the "ball" went right through the "paddle"
> >in Pong, and I hate it when I go into a room and can't pick up an
> >object that is there.
>
> In the first case, your talking about collision detection. No
automated
> test can be devised for that, a person has to look at the screen and
> decide if the ball should have changed directions, or continued on its
> course.

Of course an automated test can be written for it, given an appropriate
testing framework. I suspect that either such a framework doesn't
exist, or whoever has it is keeping it a closely held secret.

Existing GUI testing tools are both expensive and fragile;
everyone agrees something better is urgently needed, but nobody
has done it yet - as far as I know.

The thing is, if you can write a program that launches another program,
takes over the mouse and keyboard (and game device, etc.), and
can take a screen shot periodically, then it can analyze the contents of
the screen shot(s) and determine whether what it expected actually
happened. This would be a lot easier for a standard dialog box
application than a game, but the principle is the same.

> In the second, the computer doesn't know an item is there unless the
> programmer told it, and the programmer doesn't know someone wants to
> pick it up until a tester tries... Now you might say that we can make
> automated tests to ensure that the user can pick up things that the
> programmer told it was "gettable", but making sure that works is
> trivial, so what is the point of writing a test for it?

Same comment, and it's actually a bit easier than motion
detection, since *most* such situations are timing independent.

> On the other hand, the concept that test-first programming has nothing
> to do with testing and everything to do with interface design sounds
> interesting.

It's one of those points that's quite difficult to get across
to someone who sees the word 'test' and then disconnects
his brain because he thinks he knows what you are talking about.

John Roth