There is no rule mandating that the “Coding Language and E2E Test Scripting Language Must be Identical”. In fact, Mostly Better to be Different.

End-to-End testing is the process of verifying an app according to its specifications from the viewpoint of an end user. For web test automation, this simply means, E2E test scripts drive the app in a web browser.

E2E test scripts are independent of code, that’s why it fits in the category of “Black-Box Testing”. Everyone agrees with this, right? If so, the choice of E2E scripting language is nothing to do with the coding language. I have implemented a number of successful E2E Test Automation using Selenium + RSpec (in Ruby language), for apps coded in various languages, including Java, C#, JavaScript, PHP, and Ruby.

Mandating “use the coding language for E2E test scripts” is Wrong

However, in reality, in many software companies, testing managers or test architects often mandate “using the coding language for E2E test scripts”!

This is got to be the most common and frustrating cause that I experienced in test automation consulting. Even after I proved that the Selenium Ruby solution tested the app very well, and many testers (auto and manual) liked the implemented test automation, for the first time in their careers.

However, more often than not, one so-called Software Architect or Principal Software Engineer jumped out, “We must use Java (or JavaScript, doesn’t matter) as our code uses it”. This does not make sense.

Some would say, “Because they want to be able to support the test scripts after you leave?”

OK, I missed some background info, I often was called in to rescue a bad test automation implementation for a project. I have always been using Selenium WebDriver + RSpec (since 2011, prior to that, Watir). When the E2E test automation worked well, some people with a fancy title heard about it and would come to give directions. The most common action: questioning the use of Ruby language. They often acted like they had E2E test automation in control, if so, what all previous attempts failed with their presence?

“95% of the time, 95% of test engineers will write bad GUI automation just because it’s a very difficult thing to do correctly”. - this interview from Microsoft Test Guru Alan Page (2015), author of "How we test software at Microsoft"

Clearly, it was a human issue, that often cannot be resolved by technical proof. Check out this story: Principal Software Engineer Undermines E2E Test Automation.

Why is it mostly better for E2E Scripting Language to be different from the Coding Language?

Below are five popular coding languages.

1. Java or C#

Compiled language, shall use a scripting language instead. We call ‘test scripts’ for a very good reason.

Check out the following articles:

• Automated Test Scripts Shall be in the Syntax of a Scripting Language, Naturally!
• Why Scripting Languages are Better for Writing Automated End-to-End Tests? Part 1 and Part 2

2. Python

A good scripting language, however, its indenting rule is bad for E2E tests. Why? The audience of E2E tests includes business analysts and manual testers, the Python indenting can easily confuse them when they try to make simple modifications.

3. JavaScript

Popular in both coding and E2E scripting. However, it is a bad option, with a list of failed or becoming-quickly-outdated automation frameworks, such as PhantomJS, WebDriverIO, ProtrctorJS, TestCafe, and Puppeteer. Check out my article, Too Many Failed JavaScript Test Automation Frameworks!

And recently, the outlook for Cypress appears uncertain as Cypress.io is dying. By the way, every JS test automation (including Cypress and Playwright) attempt I witnessed was a failure. Disagree? maybe your definition of test automation success is different from mine. Let me show you what a successful test automation looks like, Showcase a 500+ End-to-End (via UI) Test Suite: E2E Test Automation is Surely Feasible for Large/Complex Apps.

Check out my article for technical reasons, Why JavaScript Is Not a Suitable Language for Real Web Test Automation?

4. Ruby

It is good for coding web apps and perfect for E2E scripting. According to Hired’s 2023 State of Software Engineers Report: “Ruby on Rails and Ruby are the top two most in-demand skills.”

Some will say, “Wait, did you say it is better to be different?” Yes, that view is still mostly valid (reasons will be provided shortly), but I haven’t found a good E2E scripting language that is remotely close to Ruby. If the team’s coding language is Ruby, I will be happy to make the exception.

Besides the above, the main argument for “coding language and E2E scripting language should be different” is mostly a human factor, which matters. E2E testing is to verify the developer’s work independently. With both parties sharing the same repository and most likely using the same IDE, conflicts could happen easily. Usually, Developers will take a dominant position over poor QA Engineers. I spoke with real experience. This article is quite long now, you can check the towards-to-end section of my other article, “QA Engineers, Stay Out of Cypress Component Testing, for Your Own Sake!”.

----

This article was originally published on my Medium blog on 2023-08-15.

Related reading:

• My eBooks: “Practical Web Test Automation with Selenium WebDriver”, “Practical Continuous Testing: make Agile/DevOps real”
• Testing Pyramid Clarified