What programming language should you choose for your test automation?
In many instances, but certainly not all, choose the same programming language as your development team. Choosing the same programming language can
⬆️cross-functional collaboration (Devs + QA),
⬆️ability to test across all system levels (unit, integration, system),
⬆️testability of the SUT
⬆️test code quality
⬇️barriers to tech acquisition
It might be acceptable and necessary to choose a different programming language than your dev team is when they are using a very obscure language that isn’t well supported by the community. For example, PHP, Pearl or COBOL, to name a few. If choosing a different programming language will enable better testing, then we should do it.
Here’s why:
Choose the same programming language as your dev team
Every decision in test automation either makes life harder or easier. When you choose the same programming language for test automation that your developers use, you drastically increase your chance of success.
1. Same programming language fosters collaboration between Dev + QA
Although I studied Java in college, my first experience with test automation came in the form of QTP aka UFT.
At that time, I used a horrible programming language called VBScript (RIP ⚰️).
At one point, I transitioned jobs and was forced to learn C# because that’s what our whole team was using.
Although it was frustrating initially to learn a new programming language, it ended up being one of the best decisions I have ever made for my career.
Not only did learning C# open many new doors, C# allowed me the capability to work closely with the developers to create the best possible test strategy.
As a team, we worked closely together to create the most optimal automation strategy.
We worked together to tackle unit and integration tests which replaced my UI tests.
It gets better:
When I needed help from the developers and the architects, they could easily help with their decades of C# development experience.
They would help me to create cleaner code that was better architected.
Ultimately, we all ended up winning as an organization and a team.
2. Same programming language opens opportunities for better locators
If you are using the same programming language as your developers, you can ask them if they will let you add data attributes to the software that you’re testing.
This would look something like this:
<div data-test="shopping_cart" class="shopping_cart"></div>
These are special attributes that can be used specifically to help with test automation. They will not be modified and will ensure that your locators aren’t brittle.
This is beneficial because it removes your dependency on the developers to provide you unique attributes.👏
It also reduces the workload for the devs since you won’t be asking them to provide you unique locators 👏
3. Same programming language makes software procurement and setup easier
I think you will agree with me when I say that the developers are regarded as the most important players in most organizations. Usually, if developers want some tool, they can get it procured.
As automation engineers, it’s much easier for us to simply ask for a copy of the tools that management has already paid for. Asking for the same IDE, the same CI server, the same development environments.
This is much easier than asking for a special IDE and all other software that you need to do your automation work. Now, we are causing more work for other people.
Furthermore, many organizations have separate DevOps engineers that help to create CI pipelines and procure the VMs to make those pipelines work.
If you have a random toolset that they’re not familiar with, you now introduced even more roadblocks to your automation success.
This happened to me when I wanted a QTP license. My CEO said “no”. However, I could easily pick up Selenium WebDriver in C#. We already had licenses for Visual Studio, MSDN and even BrowserStack!
4. For front-end JS web apps, tooling can make a huge difference
In this repo, Aslak Hellesoy run 100 UI tests in under a second then flips a command line argument and run 100 unit tests in a few milliseconds.
I don’t know anyone in the world who can do this in any other programming language besides JavaScript.
The right programming language choice here can either enable you or disable your possibilities.
What if your dev team uses a programming language that isn’t widely supported?
It’s also really important that as automation engineers we are capable of doing our job. Hence, we need to think about the community support for our test automation tools as well.
Choosing something like PHP or Pearl will leave us lonely when we need help with our test automation efforts.
Here’s what to do:
Consider picking a programming language that is simpler
Again, every decision in test automation is one that can keep you in the valley of success or force you out of it. So think wisely about the programming language that you pick.
Do you have excellent programming experience? For example, do you know SOLID? Do you know what it means to prefer composition over inheritance?
If not, don’t choose something complicated like Java. Maybe you’d be better off with JavaScript or Python.
Consider picking one of the more popular programming languages
When picking a programming language for test automation, it’s also important to consider your future job opportunities.
Hence, I recommend that you read this article on The Best Programming Languages
This article will help you to decide which programming language has the most potential.
JavaScript or Python might be a really good choice.
Here’s a table summary:
Use cases that hinder good testing practices
Below are some examples of programming language choices that hinder good testing practices. This isn’t a comprehensive list but it’s meant to provide concrete examples.
1. Testing in a non-JavaScript language for a JavaScript front-end web application with NodeJs backend
Testing this type of tech stack in anything but JavaScript has more disadvantages and certainly hinders better testing.
2. Using a non-Java language for a backend system build on Java
If we were to test a Java backend system in C# for example, only because we are comfortable with this language, then that is a poor testing decision and loses many of the benefits mentioned in the first paragraph.
This works the other way as well. For example, testing a C# backend with Java.
Summary
In most cases, it’s most appropriate to pick the same programming language for your test automation as the developers.
In some cases, you might consider picking a programming language such as JavaScript or Python.
What do you think is the best programming language for test automation?