Feature request: no-floating-locators

[mikedidomizio]

In Testing Library, querying (getBy*) will throw an error if no elements match. Preventing the continuation of a test.
In Playwright, locators although visually similar, behave differently, and will not fail written the same way as Testing Library. The test continues.

The differences may not be clear to some people, and can result in flakiness due to not understanding the differences between the two testing frameworks.

Some proper usages:

// variable assignment to be used later
const btn = page.getByRole('button', { name: 'Sign in' })

// a promise (user action) that is awaited
await page.getByRole('button', { name: 'Sign in' }).click()

// passing the result of the locator into an assertion
await expect(page.getByRole('button', { name: 'Sign in' })).toBeVisible()

Invalid usages:

page.getByRole('button', { name: 'Sign in' })

// continues when developer expected test to wait for 'Sign in' to be visible/attached/etc. similar to Testing Library.

My thinking is a rule (named similar to no-floating-promises) that requires the developer to use the locator in one of the following proper ways and can't "float". I can't think of a scenario where the invalid usage by itself makes sense (but let me know if I'm wrong).

• I've looked through the existing rules of this plugin and I didn't see anything that covered this.
• I've looked through Playwright options for something that might help and didn't find anything.
• I've tried to think of other cases where the invalid usage is acceptable.

[mskelton]

The idea is good, but I would rename it to no-unused-locators

[mikedidomizio]

I'm fine with the name change, easier to understand at first glance 👍.
I thought I'd take a stab at this, and have something in the works, but there's a few questions to be asked.

1. There's a number of locator methods that need to be supported in different ways

// ✅ is valid
await page.getByTestId('footer').waitFor({ state: 'visible' })

Depending on the return type of these locator methods, they might not be confirmed "used" unless there's something like the result assigned to a variable.

// ❌ technically isn't used, at least the way it is intended
await page.getByRole('listitem').all()

// ✅ is used, or we hope `li` is used
const li = await page.getByRole('listitem').all()

So the rule should depending on the return type of each one, handle it accordingly.

2. The first version will only catch "unused" locator methods if they are chained, it will not traverse if a variable is assigned

As a first version of this rule, I hope that it's fine keeping it simple where it works only for those chained locator methods

// ✅ is used
await page.getByRole('button', { name: 'Sign in' }).click()

...
// ✅ is not known if used, but is assigned to a variable so we will hope it's used
const btn = await page.getByRole('button', { name: 'Sign in' })

...

// if they don't use `await btn.click()` below, we can hope that maybe they have something like `no-unused-vars` to catch it, and we might not need to support this work at least not in the first iteration 👍

3. If Playwright introduces new locator methods that they shouldn't be reported

The rule should opt-in how each locator method is handled. Whether just await is enough, or needs to be assigned to a variable.

The idea behind that is it won't result in repos dependent on this project be blocked in upgrading to a new version, simply because this project hasn't kept up with Playwright.

await page.getByRole('button').someNewThing() // ✅ unhandled

I'm trying to ensure the rule goes smooth and consider any edge cases that might make this more difficult.

Let me know what your thoughts on this and if there's anything I may have to watch out for or haven't considered.