5 reasons you should not use Protractor in 2020
Tags: protractor, javascript, endtoend, testing
Published: 2019-09-27 12:49:15

---
title: 5 reasons you should not use Protractor in 2020
published: true
description: Protractor tests becomes a problem in 2020. Consider using alternatives today!
cover_image: https://thepracticaldev.s3.amazonaws.com/i/9tp05j5fpbghqa3f9whz.png
tags: protractor, javascript, end-to-end, testing
---



> TLDR: There is a chance that you might still want to use Protractor when version 6 is released. But not today. As of today, it is recommended to switch to modern frameworks like [webdriverio](https://webdriver.io) or [codeceptjs](https://codecept.io).

Protractor is a very popular end 2 end testing framework for NodeJS. It was started as a testing tool for [Angular](https://angular.io) Framework but then overgrew to become a de facto standard of testing in JavaScript. However, nowadays, it doesn't feel so well. The web has changed, the JavaScript ecosystem has changed, the Selenium has changed, but Protractor didn't. And if you still use it, or you consider using it because of its popularity - stop that. Today is not a good day. 

So what happened to Protractor?

# 1. Protractor is not updated

Protractor was not actively updated for a few years. No major improvements, no bug fixes, no documentation updates. You can see tons of old issues in the main repo and absolutely no movement in commits for a few months.

It also became out of sync with its main dependency Selenium WebDriver JS. Right, Protractor is based on the official Selenium WebDriver library to drive browsers over W3C protocol. However, [Selenium WebDriver was not updated for two years and now they are moving to 4.0](https://www.npmjs.com/package/selenium-webdriver). Protractor was not actively developed as well for those years, and you may see outdated documentation or long-standing issues. Protractor is almost ready to switch to this version but this still a big issue to end-users. As they will need to rewrite all their tests!

# 2. Protractor 6 will break compatibility

In Protractor 5 promises were synchronized using control-flow mechanism. This was also taken from the selenium-webdriver library. However, selenium-webdriver is dropping support of control flow in version 4. This means that once Protractor is upgraded to selenium-webdriver 4 it will drop it as well. So all your tests should be rewritten using the async/await pattern. 

Using async/await gives you better understanding and more control over promises. However, it can be harder for developers in tests to switch to this new style if they are not familiar with it. Currently, Protractor follows Java-style syntax, so engineers experienced with Java can easily go to Protractor. After a switch, each browser call should be wrapped with `await` keyword. Missing even one await will lead to broken and unpredictable tests.

So async/await is coming. You will need to update your codebase and train your engineers. The problem is we don't know when exactly it is coming! Protractor 6 was tagged but never released due to some critical issues. And no estimates when a new version will be released!

![](https://cdn-images-1.medium.com/max/800/1*VYYBBHeF0S5wZ6-ZyWVCZw.png)
(from: https://github.com/angular/protractor/issues/5290)

# 3. Protractor is overcomplicated

The next problem of Protractor is the design which is highly inspired by Java and is very complicated for the JavaScript world. Protractor adds thousands of lines of code on top of a very big selenium-webdriver library and when something goes wrong you don't have any idea why and where the bug has happened. 

Protractor tries to tie up selenium-webdriver, Jasmine, Angular but in the end, they produced a very complicated setup with huge configs, and hard to read tests. At least senior JavaScript developer is required to prepare a good Protractor setup.

Protractor exposes WebElements into tests. So instead of controlling a browser, you control only some HTML elements on a page. But you can't get direct access to those elements from a test, as your browser is executed externally. 

Wrapping hundreds of elements, calling commands on them, filtering them and mapping brings you out of the scope of testing. You spend most of the time not writing tests but fighting web elements. Congrats! Now you are a senior element controlling engineer! Whatever it means.


# 4. Protractor not driving a good design

Take a look of this code. This is quite a common picture of what Protractor tests can become. You don't understand what happens and you don't even want to look into this hell!

```js
product.element.all(by.xpath(cons.xpathproductRate())).then(function (products) {
    var i = products.length;
    (function loop() {
        product.sleep(1000);
        var product = cons.xpathproductRate(i);
        product.element(by.xpath(product)).click().then(function () {
            main.waitForElementAndClick(product, cons.linkRemoveproduct).then(function () {
                main.waitForElementAndClick(product, cons.radiobtnRemoveAll).then(function () {
                    main.waitForElementAndClick(product, cons.btnRemoveproduct).then(function () {
                        i = i - 1;
                        if (i > 0) {
                            loop();
                        }
                    });
                });
            });
        });
    })();
});
```

You can say that bad code can happen everywhere. But this is a result of overcomplicated design in Protractor. The indirect control of web elements with promises everywhere tends to drive design full of chained methods and loops.

This makes tests unstable and not readable to humans.


# 5 Protractor is not required for Angular

Protractor started as a primary tool for the AngularJS framework. It was the most popular framework for single-page applications when there was no React or VueJS. Angular is still widely popular but the truth is that you don't need Protractor to test Angular application. 

The only key feature of Protractor for Angular was synchronization. Protractor waits for Angular to finish rendering before taking any action on-page. This worked fine in the era of AngularJS 1 but it is less and less stable as Angular evolves. Modern Single Page Applications are built around components and there is no single point of truth if a component has finished rendering or not.

So instead of relying on Angular to synchronize components by some magic, it is more reliable to use explicit Selenium waits like `browser.wait(EC.visibilityOf($('#abc')), 5000);`


# So what are alternatives to Protractor today?

Today Cypress.io takes popularity. Should you rewrite your tests to it? 

**The answer is NO!**

Picking a tool by their popularity is a bad idea at first. But Cypress is quite different technology for different tasks than Protractor. It plays well for testing components of a web application, but it can't replace Protractor as Cypress does not support:

* iframes
* file uploads 
* native events
* any other browser except Chrome
* xpath
* multiple windows and tabs
* testing sites you don't control
* page objects

So if you want to have the cross-browser support for a test, rich ecosystem with services like SauceLabs or BrowserStack, you should look for other Selenium tools instead.

## [webdriverio](https://webdriver.io)

[Webdriverio](https://webdriver.io) is an alternative webdriver implementation not based on selenium-webdriver with elegant and more consistent API. webdriverio also support testing native mobile apps with appium.

As of today, webdriverio is the best webdriver implementation in JavaScript. It has rich functionality including react selectors, shadow dom support, it can even use DevTools protocol for testing! 

Unlike, Protractor webdriverio receive constant updates, it has a very active community of developers, and it just rocks!

## [codeceptjs](https://codecept.io)

Another alternative would be to use [CodeceptJS](https://codecept.io) - a framework for supercharged end 2 end testing. Unlike, Protractor CodeceptJS do not expose web elements, its tests are written in a scenario-based manner, where all actions are explained from the eyes of a user:

```js
Scenario('create todo item', (I) => {
  I.amOnPage('/');
  I.dontSeeElement('#todo-count');
  I.fillField({model: 'newTodo'}, 'Write a guide');
  I.pressKey('Enter');
  I.see('Write a guide', {repeater: "todo in todos"});
  I.see('1 item left', '#todo-count');
});
```

CodeceptJS do not control a browser by its own. Instead, it delegates a browser control to other libraries, like webdriverio or Protractor. So yes, you can still execute tests in Protractor without the pain of maintaining Protractor code! 

CodeceptJS takes a different approach in the end to end testing. But because you don't need to think about how to control web elements your tests become easy to follow, write, and debug. CodeceptJS provides you not only a tool to run browsers but best practice architecture to build sustainable end 2 end tests.

If you didn't have a chance to look into CodeceptJS, it's a good time to do so!


# Conclusion

Protractor powers lots of tests out there. But it doesn't stand a test of time. Maintaining old code written in the days of Protractor and Angular glory can be more expensive than rewriting all tests from scratch! Nowadays, it is no use to rewrite those tests in Protractor as its future is not clear. However, it's a good day to try modern frameworks like [webdriverio](https://webdriver.io) or [codeceptjs](https://codecept.io)!