"John Roth" <johnroth / ameritech.net> wrote in message news:<u241uppsuq5ia0 / news.supernews.com>...
> "Vladimir" <truediogen / my-deja.com> wrote in message
> news:4837660.0112170549.227501a6 / posting.google.com...
> > "John Roth" <johnroth / ameritech.net> wrote in message
>  news:<u1npglbd5u9se3 / news.supernews.com>...
> >
> > > 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.
> >
> > Having some test automation experience I wouldn't recommend anybody
> > doing that. Far better to rewrite whole application to get it
> > auto-testable or even better just sit down and test it manually.
> 
> The point I was trying to make (which seems to be universal experiance,)
> is that current GUI testing tools lack a lot. It should be possible to
> make
> a better one (Preferably free.) Unfortunately, that's going to take a
> bit of
> thinking. Also a reasonable amount of pattern recognition graphics
> processing.

There are tools allowing to process a screen content and return some
kind of data to be further validated but still I wouldn't recommend
doing this. I always look for better (more reliable) way because I
know how big role in GUI testing automation the test
reliability/maintainability plays.

----
Best Wishes,
Vladimir