Protractor, another Automation Framework I rightly avoided, is being Deprecated

Expensive lessons learnt for teams that do not use W3C compliant Selenium WebDriver.

By Zhimin ZhanPublished 9 months ago • 4 min read

Protractor, a JavaScript-based end-to-end test automation framework, became quite popular a few years back with the rising of AngularJS. I did a quick review of Protractor and disliked it.

The official news came in April 2021: Protractor is being deprecated. While I feel sorry for the teams that have invested a lot of effort in Protractor, my advice is to convert them into raw Selenium WebDriver with RSpec.

As a developer who worked on free and open-source software, I have respect and sympathy for Protractor developers.

“Deprecating Protractor is not a decision that is taken lightly by the team.”

It is a shame that Protractor developers chose the wrong language (JavaScript) and lacked the right mindset: they thought they were making Selenium syntax easier. However, it ended up with the opposite effect.

They should have known that the right approach is to use raw Selenium WebDriver in a good scripting language such as Ruby, with Maintainable Automated Test Design.

Selenium WebDriver find_element syntax was created by the W3C experts. It balances flexibility, readability, learning-ability and other attributes perfectly. Unfortunately, some engineers do not understand that. They created another layer of ‘better’ syntax, which actually made it much worse.

“Everything should be made as simple as possible, but no simpler.” — Albert Einstein

Let me share a story about Protractor. Several years ago, A company contacted me for help in implementing test automation. A manager there saw my work before and recommended me to his company.

During the meeting, the tech lead stated that they had started test automation using Protractor. Obviously, they faced some challenges or choices and wanted my opinion. I gave out the suggestion directly: “You should use raw Selenium WebDriver with RSpec instead”. He was surprised by my directness. After knowing RSpec is in Ruby, not JavaScript, he showed no interest. He insisted on using JavaScript.

This was what I said: “If you use JavaScript, compared to Ruby, it will cost the company 10 times more (on time and money), and 10 times higher chances to fail.” Not surprisingly, the tech lead and another manager were defensive. However, they still let me finish my demo for the sake of the manager who recommended me.

Then, I suggested that I could write one of their real automated tests right now, the tech lead was shocked. Before he could react, a tester named Alex showed interest by saying: “Good, I actually am working on one test, I can show you”. He connected his laptop computer to the projector and showed me the test steps.

I quickly installed TestWise and started writing this test live so that everyone can view it on the projector. It did not take me long to complete it. Alex was thrilled by my efficiency and the quality of the test script. Check out this article: “Step by Step showing how to learn to write raw Selenium WebDriver test scripts in minutes”, if you are interested in how I did it. (later, I was told how long it took them to create a test like this in JavaScript. See below)

The result: They decided to engage me for weekly coaching sessions.

Please note: there was no contract with my coaching. If the customers were not happy with the value I provided on every single session, they can disengage my service at any time.

Alex was very excited and revealed to me that the same test would take him 2 weeks to create. (Later, Alex finished another similar test in Selenium RSpec the same afternoon. Please note, Alex did not know Selenium WebDriver, Ruby, RSpec, or TestWise) The previous JS tests were so flaky that the tech lead told him: “Run one test 10 times, if get 7 OK, consider the test pass”, Wow!

The truth: it is quite common that tech leads who knew little about test automation and Continuous Testing often pretend that they know what they are doing.

Three weeks later, I suggested the tech lead set up a central BuildWise CT server to run all selenium tests regularly so that the execution results will be visible to the whole team. Then, they stopped contacting me. Surely, there was a human reason (BuildWise is free and open-source, it has been installed on Alex’s local machine and ran fine). My guess is that real Continuous Testing, which might expose many development issues, scared the tech lead.

That’s my experience of seeing some badly written Protractor tests. Since then, I have never wanted to get involved with this automation framework. The reason is simple: the raw Selenium WebDriver + RSpec wins with a big margin in every aspect.

There is a lot to learn/practise in Test Automation and Continuous Testing, I have to value my time wisely. I do keep an open mindset towards new frameworks or languages, though.

Not just on Protractor, I have made several correct calls (with concrete proofs) on test automation. The simple reason is that I have been doing hands-on test automation pretty much every working day since 2006, with success. I know what a good test automation process (Most IT engineers never experienced one in their careers) is.

Some might ask: “What are your predictions on automation framework such as …”. My answer is “stay with the W3C standard, i.e., Selenium WebDriver, and recommend RSpec as the syntax framework”. Avoid the rest such as Cypress, Puppeteer, TestCafe, Playwright and Cucumber. Test Automation and Continuous Testing are practical and objective. If you really like Cypress or Cucumber, do make it work, i.e. providing visible value from Day 1 (that is what I am always being able to achieve with raw Selenium). Then you can grow the test suite (more importantly, maintain all existing tests) at a consistent pace.

If your test automation is successful that meets the following criteria:

Your team members trust the test automation results and feedback
Achieve Level 3+ of the objective AgileWay Continuous Testing Grading
Your team is comfortable pushing the build to production after passing all automated regression tests.

then you are right, ignore people who tell you otherwise.