Why new-to-automation testers should learn UI Test Automation in Ruby first?
Ruby is easy to learn and pleasant to use, and the best choice for scripting automated end-to-end tests.
1. Ruby is one of the five official Selenium binding languages
Selenium WebDriver, the dominating (and only W3C-compliant) web automation framework, has five official language bindings:
This means the implementation and syntax are similar among all five of them. For example:
Ruby:
driver.find_element(:name, "user").send_keys("WiseTester")Java:
driver.findElement(By.name("user")).sendKeys("WiseTester")C#:
driver.FindElement(By.Name("user")).SendKeys("WiseTester")JavaScript:
driver.findElement(By.name("user")).sendKeys("WiseTester")Python:
driver.find_element_by_name("user").send_keys("WiseTester")Therefore, it will take no time to master another one after you master one language (ruby is the best).
Regardless of what language a web app is developed in, I could always drive it with Selenium WebDriver in Ruby, and the same way for all. — Zhimin Zhan
The fact: many of manual testers who I trained worked in test automation roles by using Java/C#/Java/Python. But they all started test automation journey, i without prior knowledge/expreience, in Ruby.
2. Ruby was the preferred language for automated testing, and it still is
Automated UI Testing started with Watir (Web application testing in Ruby).
There are also a few books on ruby for testers. Please note the subtitle of the book below: “for Teams, Testers and You”.
I believe it means that Ruby is good for team use due to its simplicity (yet powerful).
The above was to show you that Ruby is as official as it can be. It has been well-proven and suitable for test automation. Some might argue a new X framework in JS is better now. My view is still the same, Ruby is the best scripting language for test automation. I have been using raw Selenium WebDriver and always 10X (often 100X) more efficient than any JS automated testers over the last 12 years. By the way, I knew Java/JavaScript very well.
Anyway, everyone shall agree that Ruby is a suitable language for web test automation as our testing target (Web) has hardly changed. If you suggest otherwise, prove it against the Definition of End-to-End Test Automation Success.
3. Why is Ruby used less in Test Automation now?
Currently, the most popular language in test automation is probably JavaScript.
Human factors play important roles in popularity. — Zhimin Zhan
You might have heard of Protractor, TestCafe, Puppeteer, Cypress and Playwright. From my memory, Protractor was the first framework that diverted testers away from raw Selenium WebDriver around 2014. At that time, Angular.JS was super hot.
Protractor was made specifically for Angular apps
—https://protractor.angular.io
I think that was a big mistake. For app development, I am not a big fan of Angular, even less Protractor for test automation. Raw Selenium WebDriver is better than Protractor (and any later JS framework) in every way if it is done properly.
However, few people listened to me, including some of my former mentees. Check out this: “Story: A Former Mentee Failed Test Automation with Protractor”.
History proved me right. Both Angular and Protractor are being deprecated. The same pattern repeated itself several more times, “PhantomJS => Test Cafe”, “TestCafe => Cypress”, “Cypress => Playwright”. The lesson is clear: don’t chase the hype, focus on implementing real tests instead and make sure they are all valid every day. Web technologies did not change much over the last decade. See my 35-Word Functional Test Automation Strategy.
Why did so many IT professionals go for Protractor or other Java/JS libraries?
Typically, the person with titles such as ‘Tech Lead’/’Principal Software Engineer’ who decides on the scripting language/tool for test automation, often doesn’t know test automation at all. (check out Definition of End-to-End Test Automation Success and AgileWay Continuous Testing Grading to see how rare a real automation engineer is)
“Testing is harder than developing. If you want to have good testing you need to put your best people in testing.”
- Gerald Weinberg, a software legend, in a podcast (2018)“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”.
- Google VP Patrick Copeland, in an interview (2010)
Therefore, it is not surprising for them to choose the wrong scripting language most of the time. Java and C# are not scripting languages, and we call test scripts for a very good reason: Test Script shall be in a scripting language.
So, what are specific reasons that Ruby is being less adopted compared to Java, JavaScript or even C#?
Fewer job opportunities
The unfortunate reality: there are many more automated test job Ads using Java/JavaScript.
The popularity of a language is heavily influenced by commerical factors. For examples, there were software giants behind the three programming languges.
Java: IBM and Sun
JavaScript: AngularJS (Google), …
C#: MicrosoftPython is an exception, an old almost forgotten language regained new life due to the hype of machine learning and big data.
Ruby: I met Matz, the creator of Ruby and a brilliant tech genius (like Linus Torvald), who just wanted to focus on the tech. Thankfully, he kept Ruby pure and free from any bad ideas.
The opinion of “Using the same language for code and automated tests”.
This is wrong. The target of UI testing is the web element on web pages, not the code behind it. W3C-defined technologies such as HTML and CSS, and WebDriver is the only W3C-compliant automation framework.Many software engineers mistakenly thought that test automation was easy.
This is very wrong. You could meet many programmers who can manage to get features implemented at some quality. However, have you ever met a real test automation engineer that can do In-Sprint Test Automation?
4. Ruby is very easy to learn, enjoyable to use, and suitable for Team Use
As written in the classic ‘Agile Testing’ book, Ruby is “ideal” for test automation because it is “elegant, expression and tersely powerful”. Many software teams did not realize that the automated UI test scripts are for the whole team. Please see the benefits of End-to-End UI Test Automation: Executives, Managers, Business Analysts, Developers, Testers and Customers.
It is common for tech leads or architects (former programmers, now spending their time mostly in meetings) to choose a test automation framework or tool. However, they know little about test automation. If they do, they would not have time for meetings (Instead, they will work constantly to keep automated tests valid). Therefore, they usually make the wrong choice, Typically they would choose the one with which language they are comfortable, such as Java and JavaScript.
The nature of test automation is that it will be very easy to do a few simple tests (the same back two decades ago, with WinRunner or QTP), but it will be hard with maintenance. So, the chosen automation framework will easily pass the Proof of Concept phase.
However, a sinking feeling will become obvious when they put it to real use. The team is unable to maintain the tests even for a small suite such as 25 tests. To make matters worse, some programmers mandated some programming practices into automated test script development, or forced automated testers to follow certain so-called coding conventions. I often state in my consultation: “Since your coding language is JavaScript, there is more reason to avoid using it for automated test scripts”.
“Automated End-to-End Scripts are for team use, not just for programmers or test automation engineers “ — Zhimin Zhan
Below is a conversation between a manual tester and me on LinkedIn, several hours after developing her first automated tests. One afternoon, she came to ask me to develop a few automated tests. I did one while she was watching. Then I asked her to take the driving seat to write other tests with my mentoring. At the time it was 3:30 PM. She completed three tests by 5 PM. Then she went home and realized something. She asked me which language we used.
This manual tester had never used Ruby before. She (and many testers I trained) felt that the syntax was just so intuitive.
There are other technical factors (which I will cover in a separate article) that Ruby’s flexibility can greatly help with test script maintenance. By the way, maintenance is where test automation efforts are and the reason that most Java/JS test automation attempts failed. Check out this article: Is Your Test Automation on Track? Maintenance is the key.
5. TestWise Tool
A common problem that many automated testers avoid Selenium WebDriver is that they want to use a tool but fear working directly with raw Scripts, which is fair. Some tried using a programmer’s IDE such as Eclipse but found it was too complex! Some tried commercial tools such as UFT Developer but found they were not good as well as too expensive (according to this post, ~$10,000 a license). Frustrated, many teams just decide to use the same coding setup (coding language and programmer editor, such as Visual Studio Code) to develop automated tests, which is very wrong!
Using a programmer editor for developing automated tests does not seem right (Remember, test automation scripts are for the whole team, not just programmers) but many do not know there was a free or near-free option: TestWise.
TestWise is a functional testing IDE that I created from the ground up for automated UI testing (for web, desktop, mobile and API testing). I have been using TestWise for developing/maintaining automated tests since 2007. I admit that my view is subjective. However, I want to point out an objective perspective that many people have neglected: TestWise is an IDE-alike tool for testers.
A good tool helps achieve better productivity, not forcing constraints. A test automation tool must not mandate vendor lock on the users. For example, QTP is a tool + proprietary automation framework. You will be stuck if there are limitations or bugs in the tool and/or framework. Most test automation tools on the market have the same issues.
TestWise is different. It only supports free, open-source automation frameworks such as Selenium and Appium. For a test script created in TestWise, you can open it in NotePad and run it from the command line. In other words, you have total freedom.
In the presentation “Trends in Agile Testing” (2009) by Lisa Crispin, co-author of the Agile Testing book, iTest2 (TestWise’ former name) was listed as the first testing tool in the “Testing Tool Spectrum” slide (#24). Lisa used the same slide in her another talk, “Overview of Agile Testing”.
By the way, TestWise supports scripting languages such as Ruby (the most ideal language), Python and JavaScript. In addition, you can use TestWise in a free mode forever. Check out my daughter’s article: Set up, Develop Automated UI tests and Run them in a CT server on your First day at work.
Related reading: