Protractor: Feature Request: create a synchronous syntax for protractor by integrating with JSDevel/Webdriver-Sync

[tennisgent]

The repo and docs for webdriver-sync are at https://github.com/jsdevel/webdriver-sync. It provides a javascript wrapper for the java selenium API. This has a number of great benefits but the main benefit is that the javascript syntax becomes synchronous and no longer requires the use of promises or asynchronous callbacks. This makes the code much more legible and easier for QA reps to write.

It would be great to see that sort of syntax integrated with the great benefits of using protractor and jasmine.

Anyone else like this idea?

[juliemr]

Thanks for the suggestion - I didn't know about webdriver-sync, it's very interesting! We're pretty committed to using the official selenium project version of webdriverjs at the moment, but this is definitely an interesting idea

[mohit-excelindia]

This would be great addition to Protractor if implemented.
Really sometimes promises are hard to fight with while automating the web pages.

[juliemr]

I chatted with the selenium-webdriver folks about this, and our conclusion was that Promises are just the best way of doing asynchronous stuff in JavaScript. They're becoming more and more standard and familiar to JS developers, and they make the most sense here. Promises will be part of EcmaScript6: http://www.html5rocks.com/en/tutorials/es6/promises/ and the API advantages from that will be nice.

[jafd]

But you do realize that it's rather pointless to work around everything being asynchronous when all you need is a synchronous script? When writing tests, you don't need them to be event-driven. You are not writing a server. You are not writing a GUI app. You are writing a test that executes mostly top-down, and if you for once forget that protractor only creates an illusion of being synchronous (which is easy), and then try to mix it with other synchronous (or non-protractor asynchronous) code, it's going to bite you.

Never mind that most stack traces produced by protractor+jasmine that I have seen have _never_ pointed me to a line in my script that caused the failure in the first place. Which makes debugging hard. Which makes cost of tests skyrocket. Which makes it easy to forget that tests are an auxiliary tool and must be as simple and unintrusive as possible.

I still want a truly blocking protractor. Should I fork it instead?

[juliemr]

@jafd we've had lots of conversations about this, and it's true, test scripts act one-action-at-a-time so they would fit nicely in blocking. Here's the reasons we've avoided moving to blocking:

• We work with the selenium-webdriver node module from the selenium org, which uses the control flow method. Any change would have to be done in conjunction with that module.
• it requires some sort of node add ons, such as https://github.com/joeferner/node-java. This can cause installation issues and is incompatible with some setups. If a clean, simple way of making blocking calls comes into node in the future, we could work with selenium-webdriver to move to it.
• Most node/javascript developers are unfamiliar with any sort of blocking, since it's fundamentally not part of the language.

If there's an issue with stack traces not getting the correct line, please file it. We should already be capturing async stack traces properly.

I know that the control flow can be frustrating to work with, especially when debugging, and I'm happy to listen to any ideas. One featuring coming to Javascript is async/await, which will improve the situation.