Imagine a world where applications are written with automated testing in mind. Fantasy? Before you dismiss the idea, read this column. Linda Hayes makes some simple suggestions for designing for testability, including using unique names and adhering to class consistency.
You would think that as automated testing tools gain market acceptance that application developers would become more aware of testability requirements. You would be wrong.
The biggest culprit is the Web. HTML-based applications rely on dynamic content that rarely uses anything approaching a useful naming or other identification scheme for either pages or objects. But client/server systems are not immune, either. Just recently I saw one that used dynamic sub-windows that were completely name-free. The developers were proud of the fact that they were able to reuse the same window over and over, changing the contents on the fly. Well, since when did windows become a scarce resource, needing to be conserved?
The irony is that the more dynamic the application, the greater the need to test and the higher the potential number of scenarios needing to be tested, both of which cry out for automation. Yet I can't begin to estimate the amount of heartache and frustration—not to mention scarce time and money—that has been wasted struggling with the after effects of applications that were written without any concept of automated testability.
If you are lucky enough to have a development group that is amenable to constructive suggestions, here is a guideline for improving automated testability.
Sticks and Stones
The old saying was wrong. Names can hurt you—especially names that are not unique, meaningful, or persistent.
Each and every screen, window, or page (I'll call them "displays" collectively to save space) within an application should have a name that is unique in the sense that it is not reused by other displays; meaningful in the sense that it is descriptive enough to be recognizable; and persistent from one build or release to the next.
But even that is not enough. A display should be defined as a known collection of objects. This means that if the objects change—for example, fields or buttons appear or disappear based on data contents or user responses—then that is a new and different display. A so-called page or window that can completely change its contents and appearance depending on a laundry list of factors is not a page at all, it is a house of horrors. How can your automated test scripts ever verify where they are if the name of the display doesn't tell you what it contains?
As for objects, the same rule applies. An object's name should be unique, at least within the context of the display, and it should also be meaningful. It must definitely be persistent; it cannot morph from Text1 to Text2 from one build to the next, or—heaven forbid—from one instance of the same so-called page to the next within the same session.
The reason for these rules is simple. For an automated test to work at all, it must be able to recognize the application components. And to be able to work from one build or release to another, it has to be able to recognize those same components again.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.
Wishful Thinking
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.
