Skip to content

#362 - Extend prefer-web-first-assertion #382

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

MSroczynski3
Copy link
Contributor

@MSroczynski3 MSroczynski3 commented Jul 28, 2025

In this PR, I extended the src/rules/prefer-web-first-assertions.ts rule to detect another two flaky methods:

-   allInnerTexts()
-   allTextContents().

Additionally, I added handling for options argument that is useful, for example, when replacing innerText() with toHaveText() with useInnerText option. Tests for all changes were added.

This is a follow-up to #362 .

@mskelton
Copy link
Member

This isn't the right approach IMO. This isn't a one-to-one replacement, since the behavior of allTextContents is different from toHaveText.

I think we should add a lint error, but not autofix.

@MSroczynski3
Copy link
Contributor Author

@mskelton I see your point here. My thought process was connected with the fact that toHaveText() is designed to handle multiple elements and multiple text values well. That being said this rule would get lost with this problem:

        const myText = page.locator('foo li').allTextContents();
        expect(myText).toEqual(['foo', 'bar', 'baz'])`

I tried a simplified approach. Could you please let me know your thoughts?

@MSroczynski3 MSroczynski3 force-pushed the rule/prefer-to-have-text branch from 0b1c34f to 1cd4c02 Compare July 30, 2025 18:59
@MSroczynski3 MSroczynski3 changed the title Extend prefer-web-first-assertion #362 - Extend prefer-web-first-assertion Jul 30, 2025
@mskelton
Copy link
Member

We can apply an autofix if the autofix is a 1x1 match of behavior, so the example you gave would work.

@MSroczynski3
Copy link
Contributor Author

I can give it a try, but taking into account how much logic there is in the rule already, I am not sure if it won't complicate things too much. Would this merit a separate rule? Probably unlikely...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants