`el?.isDisplayed` is not a function

[nextlevelbeard]

Versions: latest webdriverio + latest expect-webdriverio, TS 5.4.3

Trigger await expect(await $$('.item')).toBeDisplayed();

Logs:

TypeError: el?.isDisplayed is not a function
    at file:///Users/user/repos/repo/e2e/node_modules/@wdio/runner/node_modules/expect-webdriverio/lib/matchers/element/toBeDisplayed.js:9:74
    at file:///Users/user/repos/repo/e2e/node_modules/@wdio/runner/node_modules/expect-webdriverio/lib/utils.js:55:96
    at Object.executeCommand (file:///Users/user/repos/repo/e2e/node_modules/@wdio/runner/node_modules/expect-webdriverio/lib/util/executeCommand.js:2:26)
    at file:///Users/user/repos/repo/e2e/node_modules/@wdio/runner/node_modules/expect-webdriverio/lib/utils.js:55:45
    at waitUntil (file:///Users/user/repos/repo/e2e/node_modules/@wdio/runner/node_modules/expect-webdriverio/lib/utils.js:26:49)
    at async Object.executeCommandBe (file:///Users/user/repos/repo/e2e/node_modules/@wdio/runner/node_modules/expect-webdriverio/lib/utils.js:54:18)
    at async Object.toBeDisplayed (file:///Users/user/repos/repo/e2e/node_modules/@wdio/runner/node_modules/expect-webdriverio/lib/matchers/element/toBeDisplayed.js:9:20)
    at async Scenario.<anonymous> (file:///Users/user/repos/repo/e2e/steps/my.steps.ts:XX:X)

[christian-bromann]

@nextlevelbeard do you have a reproducible example for it?

[sangcnguyen]

Below is my reproducible code example @christian-bromann

await browser.url("https://webdriver.io/");
await expect(await $$(`//a[@class="navbar__item navbar__link"]`)).toBeDisplayed()

It seems the current code accepts $(), not $$(). Should we add support for handling an array of elements?

[christian-bromann]

Should we add support for handling an array of elements?

What would you think the behavior should be? Should it fail if one of the found elements are not visible?

Generally we only have one matcher that allows passing in WebdriverIO.ElementArrays. I am not sure what if there is an interest in adding more as you usually only assert one element at a time. However I am open for ideas here.

[sangcnguyen]

What would you think the behavior should be?

I used to write with Selenium, Playwright. I'm hesitant because they don't have behavior like this to check if an array is displayed.

Should it fail if one of the found elements are not visible?

I think it makes sense to mark the test as a failure if one of the elements is not visible.

Generally we only have one matcher that allows passing in WebdriverIO.ElementArrays. I am not sure what if there is an interest in adding more as you usually only assert one element at a time. However I am open for ideas here.

I think for now we should improve the error messages when the function does not support taking an array element and include the documentation directly into the types file. That could help users (including myself) better understand how to use the matchers.

[christian-bromann]

I think for now we should improve the error messages when the function does not support taking an array element

Maybe we can do this for all matchers that expect that? Like having a validateInput method that throws if the input is not an WebdriverIO.Element or a Promise of that. Also agree with your further suggestions.

[htho]

I'd like to mention that the types file suggests, that these matchers should work with WebdriverIO.ElementArrays (the result of $$) as well:

    interface Matchers<R, T> {
        // ===== $ or $$ ===== // << HERE IT IS
        /**
         * `WebdriverIO.Element` -> `isDisplayed`
         */
        // ...
        }

[christian-bromann]

@htho this is due to the fact that we don't have a better type for these matchers as we currently support matchers for single elements ($) and element arrays ($$). This could be improved. However most matchers are suppose to only work with single elements.

[htho]

Ah. I did not make it clear. It's not about the type definition itself. I meant the normal comment on the first line of the interface.

L491 says the following section is $$ only: // ===== $$ only =====

But L156 claims it is about $ and $$: // ===== $ or $$ =====

Yes - those are not type comments, but I like to look at the d.ts files to better understand the API. And this comment lets me believe that the following matchers are for both.