There are times when the language of choice for your test automation is essentially already made for you, such as when you must rely on a single test developer whose programming language proficiency is limited to one or two languages. If you can make the space for an evaluation, however, it often pays to consider several options.
Factors Affecting Your Choices
Besides current expertise in a particular language among your team members, there are several other aspects that require consideration when choosing which language or languages upon which to base your test automation going forward:
- Assess how much you already have invested in whatever language you now use. This investment might involve training, IDE licensing, existing code and possibly support systems linked to running of test scripts or programs. However, holding onto an investment that is not performing well is an unwise long-term approach.
- Moving to a new language and hoping to leverage existing test code might be unrealistic. It will, at the least, require a porting and re-testing effort, which will be hampered by developers who are unfamiliar with the previous language and will push to re-write tests from scratch.
- Adopting a new language means new training costs. If the organization is planning to expand, then choosing a language that is not widely used may limit your recruiting choices.
- Although it is not a requirement, choosing the same language as the software being tested might pay dividends, especially if there is a well-developed collaboration between developer and test teams already.
The Case for a Technological Decision
As you can see, some of the factors above are clearly non-technical and deal mainly with managerial issues, such as existing language expertise within the test team. Often, managerial issues trump the technical issues with respect to language choice. However, technical advantages should not be overly discounted as these often have a significant impact on the long-term efficacy of the test organization.
In general, there is clearly a difference in programming capabilities between scripting languages, such as Perl, Python and Ruby, versus compiled OO languages such as Java, C++ or C#. The latter can do everything the scripting languages can plus a lot more, such as OO exception handling, synchronization and multithreading to name a few. It is typically easier to interface to other libraries, data sources or cooperating applications using a compiled language.
If your enterprise is or will be engaged in large, complex software projects, then these more capable languages are likely worth the additional effort and cost to utilize.
Whichever language you choose, be sure to also evaluate the editing and debugging tools that come along with it. Typically, you have a choice of IDEs and choosing the right one can make a meaningful difference in the time it takes to create, test and rectify errant test scripts or programs.
Requirements of Your Test Automation Framework
Of course, the final decision regarding testing language may be highly restricted by your choice of test automation tools, since some of them only work with specific languages. Hopefully, your automation requirements analysis led you to choose a framework that supports most of, if not all, the development tools currently under your roof.
You may find that choosing the right test automation framework more or less obviates the need to choose any particular test code language. For instance, some tools use visual test editors that require almost no programming experience.
Other frameworks use scripts but automate their creation by using keyword tests that simulate user actions in a portable way that does not require re-creating a GUI-driven test when the underlying code changes. Still other automated test tools employ record-playback to create and run tests. Overall, however, these types of frameworks are severely limited relative to what can be accomplished with scripts developed in a programming language.
We have covered many of the important issues relative to choosing an optimal testing language for your enterprise. There will always be a mix of technical and managerial aspects feeding the final analysis. You should try to balance the pros and cons, but realize that there may not be a perfectly optimal solution. The most important thing is often to drive the process to a clear and timely decision rather than attempt to satisfy all parties and constraints.