Tester Requirements

[Previous] [Next]

I wanted to keep Tester focused on doing one thing and doing it well: automating the keystrokes sent to your application so that you can unit test faster. If you've ever explored commercial regression-testing tools, you've undoubtedly seen what a wild ride they can involve, from simply controlling a window on the screen to validating all sorts of complicated and weird data of the most obscure window properties possible. I wanted to concentrate on the developer's needs during unit testing and keep Tester simple to use.

Here are the main requirements for Tester:

1. Tester can be controlled through any language that supports COM.
2. Given an input string of keystrokes, in the same format used by the Visual Basic SendKeys function, Tester can play the keystrokes to the active window.
3. Tester can find any top-level or child window by its caption or class.
4. Given any arbitrary HWND, Tester can get all the window's properties.
5. Tester must notify the user's script of specific window creation or destruction so that the script can handle potential error conditions or do advanced window handling.
6. Tester scripts can be shared with anyone on the development team.
7. Tester doesn't limit developers from extending the code in any direction they need for their shops' requirements.

As you can see from this requirements list, Tester does nothing to help you with mouse input. Although recording mouse input through a journal hook is relatively easy, if you do choose this method, don't forget about one small but critical detail: the screen resolution in which you record the mouse input is the only resolution in which the mouse input can be played back. Not many shops can live with this restriction. I can assure you that not everyone in the average development shop uses the same screen resolution. If you resolve your mouse-input problem with a hard-coded screen resolution, the scripts are basically worthless if you want to share them among your team. Another problem is that the script breaks easily if you move a control in the UI even a pixel or two. Unless you record your scripts only after the UI is frozen, a recorded script is far too fragile. The catch-22 is that if you wait until the UI is frozen, you're not doing adequate testing.

Tester probably isn't a general solution for your 20-person QA department. My intention was to build a tool that you and I, as development engineers, could use to automate our unit testing. To that end, I think Tester fits the bill. I used Tester quite a bit to help develop WDBG, the graphical user interface (GUI) debugger I developed as part of Chapter 4. The best part of using Tester with WDBG was that I saved myself thousands of keystrokes—this far into the book, I can still move my wrists!