I'm not a Perl evangelist. A lot of people I've worked with would be surprised by that. It's my strength. But I gather data, then make decisions objectively, so I find myself in the uncomfortable position of technology advocacy. This is not what I consider a flattering label, so here I'll list my excuses for the apparent prejudice.
We should always work from requirements to make decisions, so here they are:
Requirement #1: Automation Code Should Be Portable
Automated tests should be able to run everywhere when they can. This essentially means test automation should run on both Windows and Unix systems if possible. Why write code that reduces your options? The chosen automation language shouldn't limit where you can run tests. Perl is interpreted and runs on both Unix and Windows hosts with no script changes.
Requirement #2: The Runtime Environment Should be Ubiquitous
The more systems that already have the required runtime, the less testbed configuration management required. Most Unix systems already have Perl installed, so automation can start immediately.
Requirement #3: Developer Skills Should be Common
The more people that already have the automation skills, the better. We don't want to have to train our automators. If our firm can hire people from a large pool of automators that already have the skills, we're better off. New automators are therefore productive earlier. Perl is a very common automation and system administration skill, especially in the Unix community. A shorter ramp-up for new hires saves the company money.
Requirement #4: No Compilation
Automation code should not need to be compiled either. Write it. Then run it. You may need to install test code on hundreds of machines. You don't need the compile step complicating configuration management. We don't want to have to worry about chip architecture, multiple processors, or 32-bit vs 64-bit. This basically leaves us with scripting languages. Perl is an interpreted scripting language. The same script runs on any platform without compilation.
Requirement #5: Mature
We want to test our product, not the scripting language. We do not need cutting edge, nor do we need to follow the latest language fads. We need dependable. This is a business decision. It is not about entertaining the automation developers. Perl has been around for quite a while and is very reliable.
Requirement #6: Free Modules
Our productivity is greatly enhanced if there is a large developer community freely sharing code. This allows us to leverage other people's efforts and avoid re-inventing the wheel. The Comprehensive Perl Archive Network (CPAN) contains modules and scripts for solving every problem you will encounter. It's amazing how quickly new technologies will be reflected in CPAN in freely downloadable modules.
Requirement #7: Easy Extensibility
It should be easy to download, install, and test required modules once you've found them. Installation should resolve dependencies automatically. Perl comes equipped with a utilities that will download modules and their dependencies from CPAN and automatically run them through the author's tests.
Requirement #8: Built-in Documentation
The language itself should contain internal documentation facilities for every facet of the language. It should contain easy to access documentation and the ability to search the documentation and Frequently Asked Questions (FAQ) or How Tos. It should be possible to write test code that contains its own Command Line Interface (CLI) readable documentation. Perl comes with a markup language called, Plain Old Documentation (POD), and a CLI POD reader called, perldoc. perldoc has an extensive FAQ library and search facilities. Standard Perl installations also contain modules for parsing POD and using POD for user help.
Requirement #9: Rapid Development
This is where the rubber meets the road. Rapid development is the desired effect of all of the other requirements. We should be able to write code quickly. Lines is money. This means we should be able to do powerful things with very few lines of code. Perl is one of the most terse and therefore powerful languages available.
Requirement #10: Integrated Text Manipulation
Most of our automation will be about reading text, from log files, CLI commands, or sockets. Perl was designed for this and has built-in syntax for manipulating text through regular expressions.
Requirement #11: Easy Data Structures
We should be able to model data accurately without the design overhead of an object oriented approach. This means we need native hashes and arrays and the ability to nest them arbitrarily. Perl's data structures are well suited for this, without complex object oriented syntax.
Requirement #12: Easy Support
We should be able to get free support easily. Perl has an extremely active self-help open source support community. There are many web sites with tutorials and numerous newsgroups. It's very unlikely you'll have a problem that hasn't already been solved. The solutions are easily found with simple web or newsgroup searches.
As you can see, Perl meets all the requirements. That is not say there aren't other languages that meet many of them. Python, for instance, would come in a close second. Perl wins over Python primarily due to ubiquity and legacy momentum. For these reasons, where there's a choice, it's the best option for test automation.
Todd Shoenfelt
http://www.linkedin.com/in/toddshoenfelt
CPAN was replicated in many languages (with smaller number of modules, of course), but what is missing in other languages is cpantesters.
ReplyDelete