The Rise and Fall of Protractor, and Why You Should Stop Using It

[article]
Summary:

Protractor has been a popular choice for writing end-to-end (E2E) browser tests over the past decade. However, Protractor is being removed from the Angular project as of Angular 15 due to a loss of dedicated developers and the rise of better testing frameworks. Based on this state of affairs, what should developers working with Protractor do, and what tool choices do developers have going forward?

Introduction

If you have worked with Angular to build front-ends for web applications or worked with automated browser tests for an application in Angular, you’ve likely encountered Protractor. Protractor is a framework for writing automated end-to-end tests against Angular applications. While Protractor was originally designed to be used for Angular applications, it became popular enough that testers and developers wanted to use it with web applications written with other frameworks as well. In the past I’ve worked with two different projects as a test developer that used Protractor for web end-to-end testing. For a while, it was the go-to tool for such test automation.

Protractor’s popularity has gone, however, and now the project is being deprecated and removed from the Angular project. Protractor has not just fallen in popularity, but its use is also actively being discouraged. Why did this happen? And what should you do about it if your team is using Protractor now?

The Rise of Protractor

Protractor was first released in 2013. It was included in the Angular project and Angular users could install Protractor for end-to-end tests along with their front-end code. This was already a good start since Angular was and continues to be a mainstream front-end web framework. What really made Protractor shine was that it made some great design and technical decisions from a testing and JavaScript perspective.

Early in Protractor’s history, it was actively developed and maintained by dedicated engineers at Google. This meant that potential bugs, questions and feature requests would be handled by developers. For example, cross-browser support was added and maintained by the Protractor team, and there were regular releases with new features and bug fixes. If people who wanted to use Protractor had a question, they could post an issue in the Protractor GitHub project and usually get answers back. This helped Protractor grow its adoption and helped people get started with Protractor more easily.

Protractor also made a few design decisions that—at the time—were quite good. First, Protractor used the official Selenium project JavaScript bindings. This was considered a good decision since the Selenium bindings use the web standard for browser automation and the Selenium project has an active community around it. After all, if there’s an industry standard, why not use that? Second, since JavaScript is an asynchronous language but most end-to-end tests are synchronous in nature, Protractor decided to use Promises syntax and semantics to handle asynchronicity. This seemed like an excellent idea since promises were becoming a regular part of the JavaScript language and were a major improvement over callbacks. The Selenium JavaScript bindings also used promises, so there was consistency between Protractor and the JavaScript bindings.

Based on these characteristics, Protractor looked like a natural choice for writing end-to-end test automation for web applications. The overall approach that Protractor took and the fact that it was well-maintained meant that even developers and testers outside of the Angular world wanted to use Protractor.

So why did Protractor go sideways?

The Fall of Protractor

One of the first signs that all was not well with Protractor was when Google stopped providing dedicated engineers for the project. New issues and pull requests to the Protractor projects eventually stopped getting the same engineers commenting and approving changes, so changes to the actual Protractor project slowed down. Eventually there were only some part-time engineers working on Protractor, and then there were no engineers dedicated to Protractor. However, the project was still popular and even gaining in popularity as more teams adopted Angular. Over time, the number of issues and pull requests to the project increased but there weren't as many maintainers able to address those requests.

As a result of this, the Protractor project saw fewer bug fixes, feature requests getting applied, and regular releases. While this isn’t good news for any project, with end-to-end testing this became a big headache for Protractor users since browsers are always changing and test automation projects often need more integrations with other tools over time. Protractor was unable to keep up with these changes, and eventually became more and more difficult to work with.

The technical decisions that made Protractor great early on turned out not to be great in the long run. Promises were definitely better than callbacks, but JavaScript promises were eventually displaced by async/await functions. When writing Protractor tests, it was easy to see why sometimes using promises was less than ideal. Almost every test wrapped every browser action in a then() statement, which could get repetitive. Also, for more complex actions like parsing a table to looping through elements in a list, promises could become difficult to understand and debug code. The Protractor project could have made a decision to migrate away from promises to async/await functions more quickly than it did, but due to a lack of maintainers and a large number of issues coming from the community, such changes took a long time to implement. Other projects handled asynchronicity much better, leading to a better user experience and more maintainable test code. In addition to this, other projects have a larger contributor community and an extendable plugin/service ecosystem, which Protractor did not have. This led to Protractor having a growing list of issues and bugs, which made an already bad situation even worse.

Eventually the situation was not maintainable, and the Angular project decided to officially deprecate Protractor, and recommend teams move to other tools.

What's Next?

Since Protractor is officially going away, teams and individuals using Protractor should stop using it and decide on a strategy for migrating to another framework. Ultimately, this is the best approach: stop using Protractor as soon as possible, decide on another framework, and begin a migration to this new framework. Trying to stay with Protractor without such a migration strategy will, quite frankly, not work out well for most teams.

In terms of which framework to choose, that really depends on your team’s needs. Here are the most mainstream options:

  • WebdriverIO has an excellent and active community and has a great service ecosystem. WebdriverIO also has a helpful tool for automatically migrating Protractor tests to WebdriverIO.
  • Playwright is a newer framework that has cross-language support if you are considering moving away from JavaScript.
  • NightwatchJS and Cypress are also popular and have support from the Angular project itself.

Whatever you choose to do, remember that Protractor is going away.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.