What’s the Best Programming Language for Test Automation?

The global software development leader will lend industry expertise to help build open source protocol for crypto assets

If Aliaksandr Kuzikau had been asked about the best programming language for test automation 15 or 20 years ago, he might have provided a specific response. But after more than a decade in the industry, the software testing team leader at EPAM Systems looks at the practice a little differently.

“The best language for test automation is the one that test designers, test executors and test maintainers know best,” Kuzikau, who works for the San Francisco market of the product development and digital design agency, said.

Kuzikau recommends considering factors like team makeup, environment and desired outcome when choosing a language. For example, a language that works best to automate specific quality gates might not be ideal for setting up a test environment.

Language aside, for test automation to actually be beneficial, Kuzikau said engineers must run automated tests frequently and analyze test execution results immediately.

“From my experience, the most important consideration isn’t merely speed or minimum initial investment. Rather, it’s in reducing the associated test automation maintenance effort,” the team lead said.

We caught up with Kuzikau for those details, and more, below.

What is the best programming language to use for test automation, and why?

During the last 15 years with EPAM, I have built and maintained several keyword-driven, data-driven and behavior-driven test automation frameworks and harnesses. I utilized a variety of programming languages, including C#, Java, Go, JavaScript, T-SQL, MDX, 4Test and Gherkin. I also did some development in C, C++, Object Pascal and PHP.

The best language for test automation is the one that test designers, test executors and test maintainers know best. That choice of language depends on the problem you are trying to solve, the team you’re working with and the environment you plan to work in. You must consider the technology stack, system, landscape and release process.

Are you using the same language for testing as the developers use to write the software? The answer very much depends on the problem you are trying to solve. At the lowest level, when implementing unit tests (white-box testing), it’s best to use the same language as the developers to implement the actual program units under test.

At the same time, the tests at the upper levels may not have such requirements, as they are mostly black-box and language agnostic. End-to-end or system integration tests often touch different layers of the application at once. For example, user interface can be implemented in JavaScript and API can be implemented in Ruby, Python, Go, etc.

PROS OF USING A COMMON PROGRAMMING LANGUAGE...

• Developers can validate automated tests’ design and comment on their functional accuracy
• Developers can code review and align the test automation codebase with the best coding practices
• Testers can share common toolsets, licenses and utility libraries with developers
• For test automation to be beneficial, engineers must run automated tests frequently.”  

...CONS OF USING A COMMON PROGRAMMING LANGUAGE:

• The upfront effort investment
• Lack of appropriate testing support or outdated harnesses (such as unit frameworks)
• Limited test automation specialists with key knowledge of the language in question available in your team, company or market

What is the most important consideration when choosing a programming language to use for test automation?

For test automation to be beneficial, engineers must run automated tests frequently. Feedback on the build’s quality, in the form of test execution results, should be delivered promptly. From my experience, the most important consideration isn’t merely speed or minimum initial investment. Rather, it’s in reducing the associated test automation maintenance effort.

In general, good points to consider in regards to the maintainability of your test automation solution include functional completeness and reusability, as well as ability to debug and modify. How much ready-to-use functionality does it provide out of the box for your domain of concern? And how easy it is to reuse this embedded or newly implemented functionality?

The original article can be found here.