The Bane of Unit Testing: User Interfaces

[Previous] [Next]

I'm firmly convinced that Microsoft Windows developers get their carpal tunnel syndrome not from typing their source code but from hitting the same keystroke combinations over and over to test their applications. After the 5,000th time you type "Alt+F, O," your wrists are locked tighter than rebar in concrete. Without a tool to automate the tasks involved in accessing the different features of your applications, you generally have to follow some sort of script to ensure that you're doing sufficient unit testing. Testing with scripts is totally boring—and the boredom that results leaves plenty of room for human error.

Automating your unit tests will mean that you don't have to type so much and that you can quickly verify the state of your code. Unfortunately, the Recorder application that used to ship with Windows 3 and 3.1 doesn't come with any of the 32-bit operating systems. For those of you newer to Windows, Recorder wrote your mouse and keyboard interactions to a file so that you could play them back as if they were physical mouse and keyboard events. Although several third-party products that will automate your application and a whole lot more (such as completely validate every pixel in a screen comparison and maintain databases of which tests ran when) are available, I wanted something that was lightweight and geared toward development engineers. Thus, the idea for my Tester application was born.

When I started thinking about creating an automation utility, I spent some time considering exactly what I'd expect from such a tool. At first, I thought about developing a utility akin to the old Recorder application. Back in the days of Windows 3, I had a complete set of REC files to drive my tests. However, the big problem with Recorder was that it didn't provide a way to do conditional tests. If my application signaled an error during the test, Recorder just went along its merry way, playing back the recorded keystrokes and mouse clicks, completely oblivious to my application's distress. One time I wiped out half my operating system with Recorder because I was testing a WINFILE.EXE extension, and when my extension had a problem, Recorder played the delete files sequence all over the System directory. My new automation tool definitely had to have an if...then...else construct.

To incorporate conditional constructs into my tests, I obviously needed to use some sort of language. Developing my own testing language would've been an intriguing intellectual exercise, but I soon concluded that I was more interested in writing a useful debugging tool than in designing a language and dealing with YACC and FLEX. It took all of two seconds to realize that I should write Tester as a COM object—that way, developers could use my utility and still write tests in their language of choice, and I could concentrate on programming the utility's regression-testing features instead of designing a new language. My personal testing languages of choice are scripting languages, such as Microsoft Visual Basic, Scripting Edition (VBScript) and Java Script (JScript), because the testing scripts don't require compiling. The different Windows Scripting Host (WSH) scripting engine implementations have a few limitations, however, which I'll point out later in the chapter. For now, let's talk about the requirements that guided my creation of Tester.



Debugging Applications
Debugging Applications for MicrosoftВ® .NET and Microsoft WindowsВ® (Pro-Developer)
ISBN: 0735615365
EAN: 2147483647
Year: 2000
Pages: 122
Authors: John Robbins

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net