Async matchers have incorrect typings

[bad-white-cat]

Environment (please complete the following information):

• WebdriverIO version: 7.7.4
• Mode: WDIO Testrunner
• If WDIO Testrunner, running sync/async: async
• Node.js version: 14.17.1
• NPM version: 6.14.13
• Browser name and version: Chrome 91
• Platform name and version: e.g. Windows 10
• Additional wdio packages used (if applicable): "@wdio/mocha-framework": "^7.7.4"

Config of WebdriverIO By Default

Describe the bug Looks like there is a bug in typings in expects toHaveText(text: string | string[], options?: ExpectWebdriverIO.StringOptions): R Shouldn't it be like this toHaveText(text: string | string[], options?: ExpectWebdriverIO.StringOptions): Promise<R>

To Reproduce Steps to reproduce the behavior:

describe('sample spec', () => {
    it('should be logo', async () => {
        browser.url('https://webdriver.io/')
        expect(await $('p.hero__subtitle')).toHaveText('bla bla') //expect is definetely wrong, but the test passes 
    });
});

Expected behavior Test above should failed.

NOTE: I know that there is a workaround await expect($('p.hero__subtitle')).toHaveText('bla bla') //it should fail and it fails but I still think that there is a bug in typings

[christian-bromann]

Yes, I believe the types are not strict enough, thanks for raising the issue. Any contributions are appreicated.

[TuxedoFish]

@christian-bromann I'd be happy to look into this. I'll investigate it a bit more to double check any unintended consequences but seems like a minor change to the matchers 👍 . Are you able to assign me to this issue?

[christian-bromann]

@TuxedoFish any progress? We should also ensure that matchers are properly types when someone uses Jasmine and expectAsync.

[TuxedoFish]

@TuxedoFish any progress? We should also ensure that matchers are properly types when someone uses Jasmine and expectAsync.

I was struggling a little bit to test it and I was thinking of using a test repository and then linking the repository to test it out. Is there a test repository I can fork?

[christian-bromann]

You can pick one of the boilerplate projects or just bootstrap something via npx wdio ./test and pick TypeScript in the config wizard.

[TuxedoFish]

Hmm okay so I have created two tests with npx wdio ./test for jasmine + mocha. After updating the types in expect-webdriverio.d.ts I linked the repo and ran the tests but still observed the bug behaviour,

So then I thought maybe it was something to do with the expect adapter after looking at this codesandbox so I added in the async keyword to the runExpect. I found something like this being done in a code sandbox here: https://codepen.io/chivesrs/pen/zYGEZvP.

export function runJasmineExpect(fn: (...args: any) => any): any {
    // 2nd and 3rd args are `util` and `customEqualityTesters` that are not used
    const context = getContext(this)
    return {
        async compare(...args: any[]): Promise<any> {
            const result = fn.apply({ ...context, isNot: false }, args)
            return jestResultToJasmine(result, false)
        },
        async negativeCompare(...args: any[]): Promise<any> {
            const result = fn.apply({ ...context, isNot: true }, args)
            return jestResultToJasmine(result, true)
        }
    }
}

But I am still seeing the same bug behaviour. I have double checked the linking as well.

I am a bit stuck but I can keep taking a look @christian-bromann

[dietergeerts]

Any progress on this? With adding typescript linting, I get an error that my await statement is for nothing, while it has to be there....

[christian-bromann]

@dietergeerts any contributions and help would be appreciated, thanks!

[menewman]

I submitted a PR (#962) for this, assuming all we need to do is the naive change implied by the issue description: change the R return value to Promise<R> in the type file.

Hopefully that's enough to do the trick 🤞

[m4hdyar]

I have the same problem with the following configuration:

• Npm Version: 8.3.2
• Node Version: 16.13.2
• wdio: 8.3.9 But the Problem only occurs when you don't use chained promises.

The example : No problem with:

const element= browser.$('#someselector');
await expect(element).toBeDisplayed(); // its ok

But problem with:

const element= await browser.$('#someselector');
await expect(element).toBeDisplayed(); // Not ok

[christian-bromann]

@m4hdyar thanks for verifying , can you provide a minimal reproducible example I can look into?

[m4hdyar]

@christian-bromann sure just use https://github.com/amiya-pattnaik/webdriverIO-with-mochaBDD and add these two lines of code somewhere in test

const element= await browser.$('#someselector');
await expect(element).toBeDisplayed(); // Not ok

You will then get 'await' has no effect on the type of this expression.ts(80007)

[christian-bromann]

Any support on this issue would be appreciated, thanks!

[christian-bromann]

@m4hdyar I tested on your boilerplate example and don't get any errors, see:

This issue seems to be connected to v7. I am happy to merge any contributions that fix the issue for v7 but I don't think this still exists in v8. Happy to re-open if anyone can provide a reproducible example. Closing.