[RFC] Replacement for Node-Fibers

[christian-bromann]

Unfortunately the day has come where @wdio/sync can't continue to be supported anymore due to breaking changes in Chromium. The project was already discontinued and now the author has announced that Node.js v16 can't be supported anymore. The @webdriverio/technical-steering-committee would like to request comments what would be the best way to move forward. I can see a couple of options:

• find someone who can find a workaround (according to @laverdet this doesn't seem to be straight forward)
• ship WebdriverIO with a custom version of Node.js that allows support for it Node fibers (as suggested here)
• dynamically rewrite code into async code (seems a scary thing to do tbh and no one can tell if there will be a reliable way to do this)
• accept the fact that WebdriverIO code is asynchronous now and write a codemod to help transition into a WebdriverIO v8 that doesn't support @wdio/sync anymore

Any comments? Thanks!

[Xotabu4]

Sad to hear that, but actually this might be opportunity to simplify code base and make single mode to avoid confusing users what mode they should choose.

I have been teaching people how to write webdriverio tests mostly using sync mode, and it shows good results for people that does not know how async code works. But i think having typescript + some eslint rule like - no-floating-promises might simplify work with async version. Probably even some IDE plugin might be developed.

Workaround might be possible, and even might help for some time to keep sync mode available. But this situation can happen again in future.

Shipping with custom version of Nodejs sounds really hard for newcomers, and also will require huge capacity to support mac/win/linux versions. New node features support will be delayed as well.

Some kind of babel transpiler that will replace sync code with it is async version also sounds really hard, and potentially might be source of really weird problems that is hard to debug.

I vote for async future of webdriverio + codemod if possible. This will require to update a lot of documentation, and implement some sugar to make code lest await covered, like await (await $('div')).click() -> await $('div').click()

[vgrigoruk]

I vote for async future of webdriverio + codemod if possible. This will require to update a lot of documentation, and implement some sugar to make code lest await covered, like await (await $('div')).click() -> await $('div').click()

👍🏻

[thedecimalspace]

I recently completed a project on a sizeable nodejs codebase where I converted sync to use async-await using codemods.
Finding all the dependencies (and their dependencies, etc) and dealing with all the styles of grammar was a monumentous task, but I got it done, and the client is happy.

I'm happy to perform the same for anyone else willing to pay. Feel free to contact me to hear more. ([email protected])

[Gabber4K]

But sync mode is still working without any problems, why the need to move it to async? Let alone pay for it, it's not that hard, takes 1-2 days for big projects

[SergeyPirogov]

Delete sync mode and force people to start new projects with canonical async/await to be on the safe side.

[Khromchenko]

It will be quite an overhaul, but I agree with gents above. It definitely simplify wdio development itself, since we won't have to support and think of multiple versions.

Let's be real. The more we/everyone will pull this train, the heavier it will get later on.

[mohanraj-r]

accept the fact that WebdriverIO code is asynchronous now and write a codemod to help transition into a WebdriverIO v8 that doesn't support @wdio/sync anymore

For the long term I think this would simplify working with WDIO. Developing a library on top of WDIO and having to offer APIs and browser commands that support both async/sync mode and testing both has been a bit of a challenge IMO. This change would make WDIO more like other JS libs and make it more straightforward and less magical at the expense of some extra bit of verbosity. +1 for this change.

[FrederickEngelhardt]

Suggestions:

• Perhaps write a babel plugin that transforms the sync code into async code? (might make things slower)
• Convert sync to async (permanently) that supports converting sync to async in all e2e files. Could use something like jscodeshift (will make code less pretty)

[klamping]

I'm very much against shipping a custom version of node. Seems like that would be a real maintenance headache and confusing for users as well.

But also, I'd be very disappointed to see sync mode go away. Not having to litter the code with await all over is one of the big benefits of WebdriverIO to me. I'd love to see a replacement for node-fibers built, but I'd have no idea where to start on that.

[ghost]

One of the biggest differentiating factors for be between wdio and the plethora of other JS frameworks is @wdio/sync and loosing the ability to write sync code will make it harder for me to recommend wdio to clients above others

[ghost]

@jflorez-planittesting I'm curious as to why.

[jamesmortensen]

From what I understand, a babel plugin would manipulate only public APIs, not internal Node/chromium APIs as node-fibers did. Also, a babel plugin would act as an adapter/facade on top of stable, released, pure JavaScript APIs, adding async/await where needed.

I don't have much experience with writing transpilers or babel plugins, but this sounds like a more stable solution that is less likely to break with future versions of Node or JavaScript.

The biggest advantage I see of WebdriverIO vs other JavaScript test automation frameworks is not having to think about when and where to use async and await, and this reduces the learning curve for manual testers transitioning to writing automation code.

What would need to be done to explore the babel option?

[christian-bromann]

I have been thinking about options how to keep sync mode around while getting rid of Fibers. Here is a possible idea:

• a hook in the launcher can be implemented to allow @wdio/sync to manipulate all test files before worker processes are being started
• the @wdio/sync package then copies all test files into a temporary directory (keeping the directory structure they are placed in)
• a parser looks into all imports and also copies over these files, e.g. POs or utility files
• a smylink is being created from the project directory to the temporary for the node_modules
• then @wdio/sync transforms all files using our codemod tool so that
  • all sync command calls are wrapped around an await
  • all test functions that contain an await are transformed into async functions
• at the end of the test the directory is being removed

Here are some things to consider:

• the copying and transformation might add a second or two to the boot process of the whole test execution, I think that is ok
• I feel confident that we can build a reliable sync -> async transformation using codemod, however
  • I question whether stack traces will be valid after we modified the code
  • I need to look into the Babel compiler that offers sourcemaps which might allow us to keep a sane stacktrace
  • maybe a Babel plugin could help us transform the code without copy&pasting as everything will happen in memory

This is an interesting opportunity to do other kinds instrumentation with the test code. Nothing particular pops up in my head just yet but possibilities are endless.

Feedback?

[vgrigoruk]

Considering that Node 16 is already released and possible risks involved in ^ solution I am going to invest time into one-off migration of sync -> async code (for our projects that use wdio/sync). Any hints for writing a codemod?

[christian-bromann]

Please take a look into our codemod repository. The code seems in the beginning a bit daunting but you quickly understand how things work, especially when playing around with the astexplorer. I would suggest add a directory similar to the protractor one called sync-to-async so that users can use this codemod via:

$ npx jscodeshift -t ./node_modules/@wdio/codemod/sync-to-async ./e2e/

[RossVertizan]

This seems like a good suggestion. At Vertizan we see the clear benefit of sync mode (see "To sync or async?" in this blog) and while using a transpiler is not as transparent as simply installing the @wdio/sync magic, it should be possible (in time) to make something that is almost as easy to use, but is supportable and maintainable in the long term.

In the short term, now that the advice is that new projects should not use @wdio/sync, what can be done to simplify the transition from sync to async for end users. Is there a programmatic way to know if the test is being run in sync mode, async mode (or at some point in transpile mode)? Is it possible to make some of the utilities do the right thing under the hood, e.g. the browser.call method that was used for wrapping third party promises, could it be made to detect async or sync and change its behaviour accordingly, that would help with the migration of user test scripts?

I'm looking into the runner to see how the @wdio/sync package is detected, to see if I can find a flag to use to know the mode.

[klamping]

I like the idea of a transpiler as a substitute. I worry a little bit about the difficulties of edge cases with this approach, as you're modifying the end-user code.

A couple other ideas:

• If the only code that's async is the Got requests, is there a way to convert those to sync? I don't really care about sync vs async performance/blocking issues.
• One middle-ground idea is to allow chaining of commands with await. So instead of await (await $('.selector')).click(), you can just do await $('.selector').click(). I think that would help ease the pain of having to add await all over your tests, without requiring too much effort to support (I think).

[ItsASine]

+1 to @klamping 's thought of async chaining as a middle ground. I've not looked into how bad that would be on wdio's side, but trying to migrate my e2e code to async has been painful enough this week that I reverted it to wait and see what wdio suggests. Losing chaining and having promise issues within expects has been a huge hit for my work.

[jayrepo]

Just updated to node v16 and found this issue, my two cents:

Accept the fact that JavaScript is asynchronous, support sync will always require extra effort. control flow in WebDriverJS was deprecated years ago. Using async/await won't take too much effort.

Support chaining in async mode, e.g. $('#id').$('.class').click(). maybe return an ElementPromise instead of Promise like other libs.
Previous sync codes, like usages in constructor, forEach, map..., may need manual effort to convert.

[anotheruser584]

In my opinion, the biggest pain with manually migrating from sync to async is the absence of a lazy element strategy, meaning you have to do something like await (await $("#id1")).$("#id2").click().

Ability to chain elements like await $("#id1").$("#id2").click() will take much less effort.

And for those who are dependant on “non-lazy-initialization” (e.g. when you WANT the element to be not found) an additional parameter can be added get buttonLogin() { return $("#id1", { lazy: false }) }.

[boneskull]

Hi, I've never used WebdriverIO before this morning, and was looking into async mode.

I think we can all agree this is tedious:

(await (await $('#foo'))).click();

this is arguably a little better, but it's not immediately clear what style to use and when:

await $('#foo').then(foo => foo.click())

I know a lot of people are unfamiliar with (RxJS) observables and/or don't like them much, but you could create operators and instead use Observable#pipe to chain everything together:

// untested

import {from} from 'rxjs';
import {mergeMap, switchMapTo} from 'rxjs/operators';

// operator which gets an element and calls click() on it
const click = observable => observable.pipe(mergeMap(element => element.click());
// creates a new observable from the promise created by $(..)
const findElement = selector => from($(selector));

// clicks on #foo, then clicks on #bar
await (findElement('#foo').pipe(
  click,
  switchMapTo(findElement('#bar')),
  click
)).toPromise();

admittedly, this sort of syntax is a radical departure from the way developers write webdriverIO code--and will have a learning curve, as written.

My suggestion, then, for consideration: a new, stream-like or observable-like API. If WebdriverIO can't "fake sync", this could ultimately provide better ergonomics than the current state of the async API. This doesn't need to be RxJS (though it is shedding weight as of v7), but something along those lines.

(One potential advantage for WDIO contributors: the "core" API could be written in this manner, and the async API could be provided as it exists now by wrapping observables in promises (see .toPromise() above) for those who don't want to use observables.)

[christian-bromann]

I started working on a Babel transform plugin to turn sync code into async one. You can follow the progress here. I am considering renaming @wdio/sync into @wdio/compile or something along these lines and make the package for compiling/transforming the code whether it is TypeScript or whatever rather than doing it in @wdio/config like it is right now. In addition to that there could be interesting feature opportunities here, e.g. merging Node.js and browser context as follows:

browser.url('https://webdriverio')
console.log(browser.window.location.host) // returns "webdriver.io"

which will be transformed into:

await browser.url('https://webdriverio')
console.log(await browser.execute(() => window.location.host)) // returns "webdriver.io"

[alonso05]

I am not a developer, but I've wrote scripts in other tools, so I am just throwing an idea.
Maybe it could be possible to write webdriverio in similar syntax as it is on TestCafe? Create an object using await and chain it

import { Selector, t } from 'testcafe'

class LoginPage {
  constructor () {
    this.userField = Selector('#user-name')
    this.passwordField = Selector('#password')
    this.loginButton = Selector('input[value="LOGIN"]')
    this.errorMessage = Selector('h3[data-test="error"]')
  }

  async submitLoginForm(username, password){
    await t
      .typeText(this.userField, username)
      .typeText(this.passwordField, password)
      .click(this.loginButton)
  }
}

[christian-bromann]

@alonso05 WebdriverIO used to do chaining in v1-v3 and I wasn't really a fan of it. It's bad for debugging.

[christian-bromann]

Update:
I am making some good progress in the cb-sync-without-fibers branch. Writing Babel transformation seems to be a lot easier than what I was used to with jscodeshift due to its TypeScript support. Got some initial transformation implemented, e.g.:

$('foobar').click()
$('foobar').$('foobar').$$('foobar')[123].click()

const elem = $('foobar')
elem.dragAndDrop($('barfoo'))

into

await (await $('foobar')).click();
await (await (await (await $('foobar')).$('foobar')).$$('foobar'))[123].click();
const elem = await $('foobar');
await elem.dragAndDrop(await $('barfoo'));

Some issues I see:

• custom commands on elements, e.g.

  const elem = $('foobar')
  elem.someCrazyCustomCommandName()
  

  are hard to identify as WebdriverIO commands, however we could pre-parse all files to look for addCommand calls
• TypeScript support is definitely possible but will require extra work

[tehhowch]

@christian-bromann is the issue with the use of the browser global not being resolved before transpilation? If so, could the wdio/sync package export a decorator / method which page object classes could explicitly import and apply as needed? The transform could then also operate on property access of any tagged symbols.

E.x.

import { wdio } from 'wdio/sync';

@wdio browser;

export default class MyPageObject {
  //... Code that uses `browser._____`
}

[christian-bromann]

The issue is not that the browser global is not being resolved before transpilation .. the problem is that when POs are imported we have no idea if it is indeed a async page object or just a utility helper, e.g.:

export default class UtilityPO {
    getSelector (name) {
        return `prefix_${name}_foobar`
    }
}

now in the test:

import UtilityPOClass from '....'

const UtilityPO = new UtilityPOClass()

describe("my test", () => {
  it('should do things', () => {
    browser.url("http://json.org")
    $(UtilityPO.getSelector('foobar')).click()
})

if I transform the test file I have no idea what the imported page object is doing, whether it runs async or sync code which forces me to put await in front of everything. I could use decorators to tell during runtime whether the function returns async code but then I would need to wrap every function call in a test into an async expression.

[anotheruser584]

@christian-bromann I guess this is only the tip of an iceberg.
I'm personally using a wrapper class that has some additional logic, logging, retries etc.
Raw example:

class ElWrapper {
	  construnctor(selector, name) {
	  // something like:
	  this.selector = selector
	  this.el = $(this.selector)
	}

  click() {
	  console.log(`Click element with selector ${this.selector}`)
	  this.selector.click()
	}
// etc.
}

and then

const ElWrapper = require("./el.wrapper")
class MyPage {
	get loginButton() {
		return new ElWrapper('.login-btn');
	}
}

What I'm trying to say here is that the original $ functionality can be deeply nested and by the end of the day it's gonna be really hard for Babel to figure out what is click() in terms of wrapper.

[christian-bromann]

yeah particular if there is no return

[christian-bromann]

deasync turns out to not work reliably. Running into similar issues as some other folks: abbr/deasync#140. 😞

I will now look into how we can extend the Element promise to allow chaining like:

const elem = await $('foo').$('bar')
await elem.click()

[christian-bromann]

Update:

I now started working towards a simplified async usage where things like this should be possible:

await browser.url('https://webdriver.io')
const tagName = await $('foo').$$('bar').get(2).getTagName()
const elem = await $('body').$('header').$$('div').find(
    async (elem) => {
        const loc = await elem.getLocation()
        return loc.x === 30
    }
)
console.log((await elem.getLocation()).x) // 30
console.log(await $('foo').$$('bar').length) // 5

So basically all element commands can be chained. When calling $$ you can either call get to continue working with a specific element, length to get the amount of elements or call an array method on it. You can follow along the code changes in this branch.

[Gabber4K]

Hi, first of all, I'd like to thank @christian-bromann and all other guys who are working on Webdriver.IO project, it's been a blast working with the framework :)

Now what I want to ask, and this is important to me and my colleagues, how long will I be able to stay with Sync mode and Node v14?

Let's just say, that people are still using OG Selenium libraries, which are like 3~ years old (3.141.59), using old Java 1.8 and code is working, so, how long will I be able to use WebdriverIO.io v7, Sync mode and Node v14 for some similar period from this point forward? It's critical for me to know, because lots of my clients, QA trainees and all people involved in QA process are now very dependent and involved with Sync mode and it's a huge part why I chose WebdriverIO (moved from Java and didn't want to use async coding at all).

Will actual chromedriver changes affect this and I'll have to move on, update all the projects to async mode and feel some heat and pain? :)) Maybe I'm missing more points here, which I probably do, can anyone help me here with this question?

[klamping]

@KristjanQA AFIAK, there are a couple of things that will eventually cause support to end:

• Node v14 End of Life is April of 2023: https://nodejs.org/en/about/releases/
• WebdriverIO has been releasing major upgrades every year or two. I don't believe this is a set schedule, but more of a target (@christian-bromann can likely provide more info here). That said, v7 should continue working for the foreseeable future, you just won't get any updates/bug fixes that newer versions provide.
• Chromedriver updates shouldn't have an effect on sync vs. async mode. But, there may be a bug in the future with Chromedriver that a newer version of WDIO fixes that you may not get if you can't upgrade WDIO.

@christian-bromann With the updates you're looking to make with async chaining, will that effect how sync mode currently works? In other words, could someone stick with Node v14, with using @wdio/sync, and still be on the latest wdio v7 version?

Also, there's still the idea of creating a codemod to help with the transition. That should make it easier to convert any existing codebases.

[christian-bromann]

My suggestion would be to drop sync support with Node.js v8. Folks could still continue to use v7 until April 2023. We also could revive the backporting functionality so that features and bugfixes are re-applied to v7 versions.

Also, there's still the idea of creating a codemod to help with the transition.

Yes, absolutely!

[anotheruser584]

@christian-bromann so basically v7 sync get's a prolonged LTS till April 2023? Clarifying because moving to async for bigger projects is a really solid piece of work (especially when you used to abuse page object chaining).
Also I have a question on improving the protractor-like async chaining mentioned above (await $('foo').$$('bar').get(2).getTagName()). Will this be shipped as a replacement for current async approach or there will be some kind of flag that enables this? (I'm personally not using async but I guess this will be a a big change for folks who are currently using it a have to do (await (await $('#foo'))).click())

[christian-bromann]

so basically v7 sync get's a prolonged LTS till April 2023?

As with all past WebdriverIO versions we continue to support previous versions for at least a year. See also versions. So yes, whatever happened you should be able to continue run your current setup until April 2023.

but I guess this will be a a big change for folks who are currently using it a have to do (await (await $('#foo'))).click())

I don't think it is a big change. The current async behavior will continue to work with the new one. The new one just requires less awaits.

[christian-bromann]

Will this be shipped as a replacement for current async approach or there will be some kind of flag that enables this?

The new async API will be backwards compatible. So we will ship it with one of the next minor versions releases.

[christian-bromann]

Update:

I created an initial PR that will help transition from sync to async. As mentioned above we will continue to support sync until we drop support for Node.js v15 which is the last Node.js version that has support for Fibers. Until then people will be able to use sync and async with almost identical syntax. This will also help us build a codemod that will be more reliable.

My next steps will be:

• finish PR: add tests (Implement new async API #6954)
• test multiremote
• check edge cases
• update documentation to make async code examples default with option to switch to sync (Update docs to prefer new async API #6987)
• ensure TypeScript compatibility (TypeScript support for new Async API #7000)
• draft blog post about this
• re-enable sync question in configuration wizard (with big warning that this will be deprecated soon)

Question to all ❓: is there anyone who has a test suite with using async mode already and willing to validate if the new API doesn't break anything?

[anotheruser584]

Unfortunately I don't have a project big enough to spot the bugs/unexpected behavior. But nevertheless my main question would be: will the typing for $ $$ etc. gonna be changed now(in async mode)? I guess $ is not returning Promise<WebdriverIO.Element>?..

[christian-bromann]

I guess $ is not returning Promise<WebdriverIO.Element>?..

It is.

[christian-bromann]

Hey all, thank you everyone who chimed in and provided their opinion. This is why I love this project so much! We released v7.9.0 which the improvements to the Async API: https://webdriver.io/blog/2021/07/28/sync-api-deprecation. Please let me know if you run into any issues/confusions or other things. Cheers!

[staizen-alexm]

that's why i bumped into this issue.

Please elaborate, from your post I can't see if you tried what is in the docs

ahh, apologies - here we go, please bear with the length..

1. i added a custom command by following Custom Commands | Adding custom commands

// customCommand.ts
export default async function customCommand(this: WebdriverIO.Element) {
  const selector = this.selector;
  // do something here...
};

2. i created a wdio.d.ts, by following TypeScript Setup | Adding Custom Commands

// wdio.d.ts
declare global {
  namespace WebdriverIO {
    interface Element {
      customCommand: () => Promise<void>;
    }
  }
}

export {};

3. i update my tsconfig.json to indicate "include": ["./**/**.ts"]

so far so good up to this point.

4. on one of the pageobject samples generated by wdio-cli, i tried to call customCommand after calling a $(<selector>) (Line 19 below) --- as we can see, the command isn't recognized
   

5. I tried wrapping the find element call with parens and added another await outside (Line 20 above) and it works.

---

the message is pretty straightforward and makes sense, because the $() return type is a ChainablePromiseElement<Promise<Element>> and not a Element (which is what i defined in wdio.d.ts)

[christian-bromann]

@staizen-alexm thanks for the clarification, mind raising a docs issue with this content, so we can extend the docs?

[iamkenos]

thanks for the help! opened a new issue - #7767.

i'm keen to contribute, just need to know how to do it first 😅 .

[christian-bromann]

Please check out our contributing guidelines and let us know when you have any questions.

[staizen-alexm]

Please check out our contributing guidelines and let us know when you have any questions.

A yes, i've contributed before. Sorry, what i meant is im happy to contribute to the docs for this issue but im not sure how to do it without the extra parens + await.

[rashad-home]

I used to work on wdio/sync framework, then I planned to switch from wdio/sync to wdio/async.

yet some places data is not passing accurately, it moves to next function before completing full data.
eg:
expected passsing data - Test eForm
actual passing data - Te, Tes, Test e

I tried with await browser.pause(2000); yet no luck.

can someone please give me a solution for this issue. If not let me know an easiest way to transform my code from wdio/sync to wdio/async?

[jflorez]

How are you retrieving the data that you pass to the setValue function?
If you put a breakpoint at the start of the search_eFormType function can you see the test data containing the correct value?
This might be a case of you data reading function not working correctly before setValue is called

[rashad-home]

const webdriverIOHomePageData = require('../../../files/testData/sampleHome.data.js');

It happens only in few areas. I'm getting the credentials from the same file, yet that never had an issue. if it's something "data reading function not working correctly before setValue is called", I should have face the issue when login to the system.

[rashad-home]

@christian-bromann issue #7866 is related to this given example.

[thedecimalspace]

I recently completed a project on a sizeable nodejs codebase where I converted sync to use async-await using codemods.
Finding all the dependencies (and their dependencies, etc) and dealing with all the styles of grammar was a monumentous task, but I got it done, and the client is happy.

I'm happy to perform the same for anyone else willing to pay. Feel free to contact me to hear more. ([email protected])

[em]

Sent you an email

[jamesmortensen]

In regards to deprecating @wdio/sync, we are in the process of converting code from sync to async and we have some promise-based libraries wrapped up in browser.call methods. We know @wdio/sync is deprecated, but what about browser.call? The docs do state that it's not needed anymore, but there are examples of it with async mode.

How pressing is it that we also remove these right away? Is browser.call also deprecated and when would it be removed?

Thank you!

[christian-bromann]

but there are examples of it with async mode.

Where is that? The call command is really not needed at this point. Every occurrence can be replaced as follows:

// async call command to replace, e.g.:
const result = await browser.call((async () => { ... })
// can be replaced with
const result = (async () => { ... })()

Is browser.call also deprecated and when would it be removed?

I think we will remove it in v8

[jamesmortensen]

but there are examples of it with async mode.

Where is that? The call command is really not needed at this point. Every occurrence can be replaced as follows:

It's here in the documentation for browser.call:

it('some testing here', async () => {
    await browser.url('http://google.com')
    // make an asynchronous call using any 3rd party library supporting promises
    // e.g. call to backend or db to inject fixture data
    await browser.call(() => {
        return somePromiseLibrary.someMethod().then(() => {
            // ...
        })
    })

    // example for async call to 3rd party library that doesn't support promises
    const result = await browser.call(() => {
        return new Promise((resolve, reject) => {
            someOtherNodeLibrary.someMethod(param1, (err, res) => {
                if (err) {
                    return reject(err)
                }
                resolve(res)
            })
        })
    })
});

I think we will remove it in v8

Ok. Thank you for the example. We'll get to work on converting that as well.

[pyxis828]

What about the REPL? I converted my project from sync to async, but am still using node v14 so that I can use the REPL in sync mode, as I find this the best way to debug. I suppose you could use it in async, but I couldn't quite figure out how to pass the commands properly without any docs, and I am bad at writing async code without any reference.

[ayushi-singhal]

I have node version 18 and using wdio lib but failing due to same error:
Assertion failed: (thread_id_key != 0x7777), function find_thread_id_key, file coroutine.cc, line 134.

This error is coming for some other service in same repo but e2e test cases repo is working fine.

This is my package.json for e2e tests:
"dependencies": {
"@wdio/cli": "^8.29.0"
},
"devDependencies": {
"@wdio/allure-reporter": "^7.16.11",
"@wdio/local-runner": "^7.16.12",
"@wdio/mocha-framework": "^7.16.11",
"@wdio/spec-reporter": "^7.16.11",
"@wdio/sync": "^7.16.12",
"allure-commandline": "^2.24.1",
"chromedriver": "^119.0.0",
"wdio-chromedriver-service": "^7.2.6",
"wdio-reporter": "^5.0.0-alpha.7"
},

This is how I am writing tests(just a random vague example):

it('Submit functionality', async () => {
await browser.keys('PageDown');
await browser.keys('PageDown');
browser.url('/logout');
})

Still facing the issue. I tried removing wdio/sync but it broke the tests execution in e2e package.

[christian-bromann]

@ayushi-singhal we strongly recommend to update WebdriverIO to v8, this package is not supported anymore.

[ayushi-singhal]

Hey @christian-bromann Thanks for your reply. I removed wdio/sync dependency and it worked for me.

[ayushi-singhal]

As mentioned in above comment of mine, I have used the same configuration and my tests are failing due to below error:

Timeout of 120000ms exceeded. The execution in the test "Open page and verify page title" took too long. Try to reduce the run time or increase your timeout for test specs (https://webdriver.io/docs/timeouts).

I can share one more sample test specs:

describe('User Page', () => {

it('Domestic user page', async () => {
    UserPage.open('user-page/')
    await expect(await UserPage.getHeading('Page')).toHaveText('Domestic User Page')
    // await browser.pause(5000);
})

});

[ayushi-singhal]

What I see is only the Urls are getting opened by it keeps loading like the website is slow but does not perform any operation further.