Imagine a world where applications are written with automated testing in mind. Fantasy? Before you dismiss the idea, read this week's 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)