Powered by discountASP.NET
referal ID: sdtref
Why recommend discountASP.NET?
$720 in referrals so far!

About/Contact

Steve Trefethen

Steve Trefethen is a Software Architect and Director of Software Training at Falafel Software in Capitola, CA. You can reach Steve here.

All opinions you read here are Steve's own and are not necessarily those of Falafel Software.

Calendar

<<  September 2010  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar

Disclaimer

The posts on this weblog are provided AS IS with no warranties, and confer no rights. The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
If you're new here, you may want to subscribe to my RSS feed, follow me on Twitter, or subscribe via email. Thanks for visiting!

Driving the keyboard and mouse for test automation

October 20 2006 4:35PM
I've mentioned Zombie a number of times, our internal GUI automation tool, and one of its core features is that it drives the GUI the same way a user does, via the keyboard and mouse. Zombie is designed to mimic normal user input by driving the UI under test using the low level keybd_event and mouse_event Windows API's. The design is intentional and prevents testers from writing automation that would manipulate a UI in ways not available to a human user. This gives us
  • assurance that if Zombie reproduced a problem a user could too
  • dramatically improves the chance of manually reproducing whatever problem was encountered
As a result for a test writer it's important to understand exactly how Zombie manipulates the GUI to give them the best chance of reproducing the same problem manually. In fact, recently I've started a page on our internal wiki which explains the internal workings of Zombie so that our QA staff has a better chance at reproducing any problems.

Back in 1994-5 when Zombie was first implemented it leveraged a DLL from Microsoft Test to handle the driving the keyboard and mouse but when we moved to Win32 in the Delphi 2.0 timeframe we had to replace the DLL with our own code that worked on Windows NT. In fact, even today the Delphi Unit that contains all of our core mouse and keyboard routines is called MSTest.pas. I sort of laugh when I open this file and see the PVCS comments at the top where my earliest comment reads:
 *    Rev 2.6   12 Jul 1995 12:42:02   STREFETHEN
* Added a functions that provide mouse click support for TreeView and Header
Ah, now those were the good old days!

Update: I almost forgot, I recently posted a Flash movie of Zombie running against Highlander here.
FacebookDel.icio.usDigg It!

Tags: ,

Comments

10/21/2006 7:46:39 AM #

Thanks... that answers my question of your previous post.. Wink

Lluis (Albert Research) |

10/21/2006 10:28:40 AM #

Great post and thanks for posting the movie!

I just spend a week of crunch time implemeting testing almost exactly like what we can see in the video, except I send messages to my app instead of using the low level keybd and mouse event functions! Great timing!

I wonder, do you guys test everything in the GUI using automated testing? I'm currently pondering on how to select the features that would benefit most and I have a hard time deciding.

Eric Fortier |

10/22/2006 3:05:25 AM #

Lluis, you're welcome I'm glad this answered your question.

Eric, no, not everything in BDS is tested in an automated way. Our automation tools allow for testing the entire product but there aren't tests written that cover aspect of the BDS UI.

Steve Trefethen |

Comments are closed