wdi5 complying with wdio's "async" notation

[vobu]

wdi5 as of now allows for sugar-coated pseudo-sync style of writing tests:

it('should be truthy', () => {
    const result = browser.asControl(selector)
    expect(result).toBeTruthy()
})

(execution of the test is actually async, but the notation looks sync)
This was possible by re-using that feature from wdio, which itself utilized the fibers node module for making sync-style notation possible.
fibers was declared obsolete by the author as it won't work with Node >= 16 and that's why wdio deprecated bespoken sync-style notation and will drop support from April on.

📢 This means we also need to adapt wdi5 to follow along with wdio, drop sync-style notation, and adapt the JS standard async/await "async"-style.

This will result in a breaking change - as we're not on 1.0 (yet), the next minor version of wdi5 will contain the async-rewrite.

For all wdi5ers out there, this unfortunately means that you have to adapt your tests in order to support any future wdi5-versions. The above "sync" example would then look like:

it('should be truthy', async () => {
    const result = await browser.asControl(selector)
    await expect(result).toBeTruthy()
})

Even though this creates additional work for all, including us, we will benefit in the long run from moving closer to the asynchronous coding standard in JavaScript. There are a couple of major feature additions planned for wdi5 in 2022 that need async/await as a prerequisite. But 🤫 , no spoilers (yet) 😸

EDIT: async notation rewrite done with v0.8.0

[vobu]

and it seems we'll be able to do:

const items = await browser.asControl(listSelector).getItems()

(instead of awaiting every async call like

const list = await browser.asControl(listSelector)
const items = await list.getItems()

)

this would even further reduce migration efforts - on both your and our side 😄
for you, porting tests written in sync-style would merely mean adding async in the it-callback and few(er) awaits.
for us: given that wdi5 tests itself with wdi5, we're essentially doing ourselves a favor saving refactoring effort 😄

[cwang1221]

Hi @vobu, I'd like to know when will this async feature be delivered? For now I could only use node < 16 and use sync in wdi5, right?

I think you know that recently many teams in SAP are doing research to migrate from UIVeri5 to WDI5 (we are one of them). As a WDI5 rookie I should directly start my research with async, right? But it seems not possible now.

Thank you and best regards,
Cong

[vobu]

the overall situation with UIveri5 and wdi5 is a bit of a limbo, but things will straighten out during January, with official announcements and such.
that being said: we‘re about 75% through with the async notation rewrite. In fact, the core functionality is already complete (see #91), but we wanted to get the fluent async api in for a better coding experience.
const title = await browser.asControl(listSelector).getItems(3).getTitle()
we cracked the approach in principle, but still need to get it into the codebase.
plus not all tests are rewritten yet.
overall, I guestimate we‘ll be done in 2 weeks max. So a little more patience, please :)

[vobu]

async refactoring is complete, including the fluent async api https://github.com/js-soft/wdi5#fluent-async-api !
go go go 🏃😁

[vobu]

first alpha release of async notation support available: 0.8.0-alpha.0, https://www.npmjs.com/package/wdio-ui5-service

[vobu]

and with v0.8.0, the fluent async api is in!
const items = await browser.asControl(listSelector).getItems()
docs at https://github.com/js-soft/wdi5#fluent-async-api

[cwang1221]

Hi @vobu , the async api works quite well! 👍 One thing I found is, seems that a fluent "click" is not supported yet.

This one work:

const button = await myButton.getWebElement();
await myButton.click();

This one is not working:

await myButton.getWebElement().click();

Error:

[vobu]

let's continue in #136