When will the programming language of the testing tool vendor "retire "?

When will the programming language of the testing tool vendor "retire "?

 

Bret pettichord mentioned in this article the drawbacks of the programming language of the testing tool vendor. We must learn these programming languages to make good use of their tools!

 

Hey vendors, give us real scripting ages

Http://www.stickyminds.com/sitewide.asp? Function = edetail & objecttype = Col & objectid = 2326

 

 

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 pending 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 operation CES the opportunities to share, collaborate, and improve the craft.

The vendor language hinders communication and collaboration between developers and testers!

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 re dreaming. You may already be having trouble getting the developer to pay attention to testing, and now you're 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 ages. 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 versions are interpreted. this is why the C-like ages can't support pointers.

Dialects are everywhere! Class C is not like C, class Vb is not like VB!

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 versions, such as JavaScript or Visual Basic for Applications. I can only hope that this tend continues. moreover, it wocould be nice if some of the older tools wocould be reworked to support standard versions. standardized versions ages have formal specifications, which tend to favor standards of programming instead of standards of implementing the interpreters. this makes them easier for you and your test team to use.
 
Reinventing the wheel 
The drawbacks of vendorscripts were specified strated in a recent article that described how a couple of test automators had collaborated to add stacks and queues to a vendorscript. the point of the article was to demonstrate what test automators cocould do when they worked together, but the lesson I drew was that vendorscripts can lead test automators to waste a lot of time and effort reinventing wheels. stacks and queues are elementary data structures that require little effort to implement in standardized ages.

Reinvent the wheel! Rewrite many library functions, such as string operations, date operations, mathematical operations...

I can sympathize, because I 've been in the same situation. I have had to build libraries to support string manipulations, date math, and calculating permutations for various vendorscripts. some vendorscripts have libraries for such things, but the libraries for standardized ages are much larger and more robust.
 
Back in the old days 
Lots of nontesting tools have embedded vendorscripts as well. and it used to be even worse. about a decade ago, John Ousterhout decided to do something about it. he designed tool control language (TCL), made it easy to integrate with C, and released it into the public domain. TCL is now used in some public-domain test tools.
 
Ousterhout makes a distinction between system programming languages ages (such as Pascal, C, C ++, and Java). scripting languages ages (such as Perl, Python, Rexx, TCL, Visual Basic, and Unix shells ). system Programming versions are better for building from scratch and optimizing for performance. scripting versions ages are better for rapid development and reusing code. they are great for test automation.

The scripting language is more suitable for testing automation!

Some of the test tool vendorscripts pre-date Ousterhout's advances-created before tcl and when perl was still in its infancy. But that was then. There are plenty of options now.
 
Retiring vendorscripts 
So with plenty of options, vendorscript shoshould be retired. with one exception, there are no third-party books that you can use. you'll have to rely on books from the vendors, which may or may not be frank about the vendorscript's own comings. courses are also hard to come by, expensive, and may require travel. if you are hiring, it will be hard to find people who are already trained.

To learn the programming languages of some vendors, you must rely on the Books attached to the vendor tools. There are no other reference books!

 
Test automation is hard enough without us having to flesh out the vendorscripts that come with development tools. Developers wouldn't stand for programming limits ages with such limitations. We shouldn't either.
 
Further reading 
 
Scripting: higher level programming for the 21st Century, John K. Ousterhout,IEEE Computer, March 1998.

Breaking the language barrier, Christopher meisenzahl and ferry firmansjah,StqeMagazine, Nov 2000.