feat(@angular/cli): migrate e2e tests to async/await

[dubzzz]

Protractor recently introduced a breaking change in version 6.0.0: no more custom control flow, everyone should use async/await instead.

Source: https://github.com/angular/protractor/blob/master/CHANGELOG.md

Control flow is removed and you should use async await to run your tests.

This behaviour is already accessible in versions before 6.0.0 under the flag SELENIUM_PROMISE_MANAGER=false.

By setting this flag to false - which is the default in 6.0.0 - I hope to reduce the migration time of new users of Angular using the CLI and using Protractor for e2e.

I personnaly did the migration 2 years ago and I believe it is preferable to start directly in async/await mode. It makes the test easier to read and futurproof.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[dubzzz]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[vikerman]

Thanks for the PR!

We discussed this in our team - This also needs a migration script to migrate all existing Protractor tests. We decided not to do it for now because of priorities.

Will revisit this as part of our next major release.

[dubzzz]

@vikerman @alan-agius4 Please let me know as soon as you'll be ready to merge such PR. For the moment it is more like a proposal for a PR. I am not sure we need to wait for a migration script to do that. In a way, it would be better for new users to start directly with the async/await mode (easier to understand, faster).

Protractor migration feedback

In a sense a migration tool from Protractor with custom promise manager to async/await would be a nice thing but in reality the two approaches are not fully equivalent. Protractor in async/await mode is far faster than the old mode. The async/await mode can create port exhaustion quite easily on Windows on code like:

element.all(by.repeater('todo in todoList.todos'))
      .filter(todo => todo.getText().then(label => label.indexOf('#10') !== -1))
      .each(todo => todo.element(by.css('input')).click())

The same code with async/await runs out of ports see angular/protractor#4706 and https://github.com/dubzzz/protractor-move-async-await

In my current company we did the change but it was more than just putting async and await where it needs, we needed to tweak some of our page objects to avoid port exhaustion (to be able to run our tests on Windows).

[alan-agius4]

Closing since this no longer the recommended path since protractor version 6 is deprecated.

[dubzzz]

We can maybe bump towards the latest version of protractor instead?

[alan-agius4]

Version 7 is essentially the same as version 5, but includes some breaking changes.

The CLI version 10 already uses version 7.

[devoto13]

Is there an issue or publicly shared vision on how team plans to move forward with Protractor? I'm afraid that we will be stuck with undebuggable control flow same as we're stuck with zone.js without support for native async/await for several years and no clear way forward.

As for a migration path for existing apps. Maybe a fixer based on no-floating-promises + some iterations testing it against Google's codebase and improving fixer and Protractor types will solve most of it?

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}