Skip to content

Extend prefer-explicit-assert to report findBy* and waitFor #409

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

Closed
zaicevas opened this issue Jul 18, 2021 · 3 comments · Fixed by #421
Closed

Extend prefer-explicit-assert to report findBy* and waitFor #409

zaicevas opened this issue Jul 18, 2021 · 3 comments · Fixed by #421
Labels
enhancement New feature or request

Comments

@zaicevas
Copy link
Contributor

With prefer-explicit-assert enabled, getBy* usages without expect are reported, but findBy* and waitFor are not reported:

    screen.getByText('hey') // reported
    await waitFor(() => screen.getByText('hey')) // not reported
    await screen.findByText('hey') // not reported

What if we extended prefer-explicit-assert to report all of the above cases? 🤔

@zaicevas zaicevas changed the title Extend prefer-explicit-assert to report findBy* and waitFor Extend prefer-explicit-assert to report findBy* and waitFor Jul 18, 2021
@MichaelDeBoey MichaelDeBoey added the enhancement New feature or request label Jul 18, 2021
@Belco90
Copy link
Member

Belco90 commented Jul 18, 2021

Hey @zaicevas! Few comments about this improvement idea.

What about findBy* usage saving returned element within a var? That should not be reported.

Not really sure about reporting waitFor + getBy* query, since inside waitFor callback the user might have other necessary stuff there.

I'd go just for reporting findBy* usages for now. What do you think?

@zaicevas
Copy link
Contributor Author

What about findBy* usage saving returned element within a var? That should not be reported.

Makes sense to me, since const foo = screen.getByText('hey') is not reported and there's no reason the behaviour should be different for findBy*

Not really sure about reporting waitFor + getBy* query, since inside waitFor callback the user might have other necessary stuff there.

Can you give an example to better understand what you have in mind?

I'd go just for reporting findBy* usages for now. What do you think?

Sure, I'd imagine these 2 cases having separate PRs anyway.

@Belco90
Copy link
Member

Belco90 commented Jul 20, 2021

Not really sure about reporting waitFor + getBy* query, since inside waitFor callback the user might have other necessary stuff there.

Can you give an example to better understand what you have in mind?

I don't have a really clear example in mind, to be honest. This is similar to no-unnecessary-act rule assuming there could be non-react-testing-library things inside act, in which case we need to allow.

This is a stupid example, but I'm not sure it should be reported:

const promiseA = new Promise()
const promiseB = new Promise()
// ...
await waitFor(async () => {
  await promiseA;
  await promiseB;
  screen.getByRole('button')
})

It's obvious it should be rewritten to just do await screen.findByRole('button') instead of the whole waitFor, but could be a legit case were using waitFor + awaiting promises + asserting with implicit getBy*? I think there must be for sure, so I'd say just leave the rule complaining about that standalone getBy* query should be enough.

What do you think?

@Belco90 Belco90 linked a pull request Jul 20, 2021 that will close this issue
Belco90 pushed a commit that referenced this issue Jul 20, 2021
* feat: extend prefer-explicit-assert to report standalone findBy* queries

* feat: add comments to make if branches more clear

* feat: update README

* fix: add tests and fix bug when return statements are reported

* refactor: rule description, add TODO

Co-authored-by: Mario Beltrán Alarcón <[email protected]>

Relates to #409
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants