Feature request: Promise-based client interface

[mbixby]

This would allow for interleaving synchronous and asynchronous code with nicer syntax. Promise.all could be used to parallelize commands. Adding breakpoints in between commands would work as expected, making live coding easier.

await client.url('http://www.google.com');
await client.waitForElementVisible('body', 1000);
const title = await client.title();
expect(title).to.contain('Google');

(similarly with yield or plain promises)

See https://github.com/theintern/leadfoot/blob/master/Command.js for more examples.

Is this realistic?

May be related to #121 (conditional test parts).

[Matthew-Davey]

Must agree with this. I've been poking around in Nightwatch a lot recently and it's just crying out to be implemented with promises!

[mucsi96]

+1

[volodya1805]

+1

[gabzim]

+1

[aikeru]

+1, please

[deanrad]

+1 though I fear this would be against the grain. Nightwatch does not appear interested in normal programming concepts— being limited to the fluent interface, while frustrating to real programmers who want to add breakpoints, control flow etc, is a boon to folks getting off the ground with less programming skill. I'd love to see a prototype @mbixby - I was just pondering whipping up an interface this morning whose promise resolves with an object of {client, result}, so promise steps could chain, but also get the results of an elements query, for example.

[DutchKevv]

+1

[beatfactor]

I'm afraid this is not on the agenda for the near future, but we'll keep it in mind for a more significant upgrade later down the path. For now I'm closing it since it's open for a long time.

[dilipkumar2k6]

Missing Promise support is big setback for me as a developer. Can you please add Promise support? I would be happy to do PR if ready to accept.

[pkantsedalov]

Has anybody tried sequenced? Maybe it can be temporary solution for devs & automation QAs.

[cheapsteak]

This is supported by webdriver.io and nightmare Wish for reconsideration

[mbixby]

A while after starting this feature request I realized I can achieve this by switching to a blocking API for Selenium in Ruby. I can whip up pry debugger and develop and tweak my Selenium tests live (while stopped on a breakpoint inside the program) without needing to rerun the test case in context.

There are some JS libs for Selenium with blocking API (Testium) but the debugging experience seems to be inferior.

[twiggy]

+1

[alexpanov]

I can't believe that this hasn't been addressed in more than 2 years.

[JonEustace]

Agreed.

[leegee]

Lack of Promises is a real deal-breaker.

[metareven]

This is a huge issue for me as well. This was OK back in the day before native promises were a thing, but now this means that we cannot write "normal" javascript code for our integration tests

[HareshVelusamy]

+1