Class Will Tell
Another requirement for testability is consistency, and here I am referring specifically to object classes, methods, and properties. The class library for an application should be well defined, which means not allowing developers to sneak in their favorite class just because they used it before, or having three different classes for the same type of control. And, for each class, the methods and properties should be used consistently. Names should be unique but other properties should not be, and methods should be exposed and available.
For example, how many ways are there to implement a combobox? I have seen at least four: 1) allows you to type in the selection or select it; 2) allows selections only, no input; 3) moves the selection list to the item based on the letters being typed, moving around the list for each letter; and 4) selects the items closest to the typed input. I'm sure there are others, but the point is…why do we need them all? It just makes your test scripts long and complicated, and most likely will keep your end users off balance.
Along the same lines, methods and properties should be made available, not private or hidden. Many a time have we wrestled with grids that did not expose the basic methods needed to get or set the contents of a cell. What's the big secret, anyway?
The reason for class consistency is that test tools rely on the object class, methods, and properties to interact with the application components. Inconsistency causes complexity, and disagreeable objects that won't share their contents make it difficult, in some cases impossible, to automate at all.
Now you might think these suggestions are pretty simple and obvious, and the truth is that they are simple, but based on the current state of application development, they must not be obvious.
But what if applications were actually written to enable automated testability? What if each application had an interface that allowed a test tool—or any other language, for that matter—to enumerate the active display and all of its objects? What if the test could request an object by name, and could access all the methods needed to set or verify any of the properties exposed to the user interface?
Gee, if that happened, what would all of the automation scripters do? Probably get the application tested on time and within budget.