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?
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
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.
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.
Eventually the situation was not maintainable, and the Angular project decided to officially deprecate Protractor, and recommend teams move to other tools.
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.
- 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.