Hey Vendors, Give Us Real Scripting Languages


Most test tools come bundled with vendor-specific scripting languages that I call vendorscripts. They are hard to learn, weakly implemented, and most important, they discourage collaboration between testers and developers. Testers deserve full-featured, standardized languages for their test development. Here's why.

For most of the test tools available today, you have to write test scripts in the tool's scripting language. What drives me crazy is that most vendors have their own special language that you must learn in order to use their tool. They often have recorders to help you generate code, but invariably you need to go in and make changes and write code yourself. And you end up having to learn another language, another vendorscript, another dialect that is good for nothing but the one tool.

Undermining Collaboration
Because a vendorscript is a specialized language, developers are less likely to know it and little inclined to learn it. I frequently counsel testers and developers to work together on test automation projects. There are many reasons why this is a productive collaboration, but vendorscripts get in the way. They split testers from developers and from each other into tool-specific language isolation. This reduces the opportunities to share, collaborate, and improve the craft.

We have enough trouble bringing developers and testers together in the testing process. The last thing we need is an inherent obstacle from the get-go in our testing tools. Ask a developer to learn Visual Basic? No problem. They can always use that knowledge in the future. Ask a developer to learn a specialized language unique to one tool? You're dreaming. You may already be having trouble getting the developer to pay attention to testing, and now you're asking for more. Why spend money on a tool that's going to undermine the collaboration efforts between testers and developers?

Dialect Stew
There are various dialects of vendorscript. Some use C-like languages. What does this mean? It means that the code looks like C, but it doesn't have pointers, so you can't use any of the complex data structures that you learn about in any C course or book. C is really a poor basis for a scripting language. It is compiled, while test scripting languages are interpreted. This is why the C-like languages can't support pointers.

Others use a Visual Basic-like dialect. If you know Visual Basic, the code will look familiar, but you won't be able to make use of standard Visual Basic libraries. Moreover, the things you learn about Visual Basic may or may not apply to the vendorscript.

Still another tool uses an object-oriented mongrel vendorscript. Being object-oriented is nice until you learn that modifications to a class won't be inherited to its subclasses. What? This vendorscript thinks that this is a better arrangement for testing. Whether this actually helps testers is debatable, but what testers really need is not a special language designed for testing. Rather they deserve and work better with a full-fledged language.

Some of the newer test tools are using real scripting languages, such as JavaScript or Visual Basic for Applications. I can only hope that this tend continues. Moreover, it would be nice if some of the older tools would be reworked to support standard languages. Standardized languages have formal specifications, which tend to favor ease of programming instead of ease of implementing the interpreters. This makes them easier for you and your test team to use.


StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.