| || |
Handling custom controls
I've read through the various posts regarding how much support is available for custom controls in the major automation tools available with regard to testing the GUI of an application. I've also gone through the vendor literature and some of the user guides. The information currently available states that way to handle custom controls is by mapping the custom control to one of the standard windows controls e.g. radio button, combo box, etc. But what if the custom control is not similar to any of the standard windows controls? Can one still manipulate the control with WinRunner or SilkTest? How much can one do with such custom controls? I assume that having the source code would help. How much of a difference would this make? Or is it just too much hassle to handle custom controls with the tools currently available?
Re: Handling custom controls
It depends on the custom control.
If the custom control responds to some of the same messages as a standard control, then treating them both the same (via mapping, for example) can be very effective.
If the custom control is not at all similar to a standard control and doesn't respond to standard messages, then mapping won't be as useful.
Still, that doesn't mean automation isn't possible.
Many vendors have toolkits to allow you to build your own interface to the custom control. (This can sometimes be a fair bit of work).
Some shops choose to build a .dll to interface with the custom control and access this .dll in their test scripts.
Sometimes, data can be copied to the clipboard via standard keystrokes and accessed from there.
Sometimes, developers can enhance the custom control to respond to special keystrokes in a test-automation-friendly way.
You need to compare the hassle of handling the custom control with the benefit you'll gain by automation.