new rule: no-multiple-assertions-wait-for

[renatoagds]

Following the proposed in Kent at his post (https://kentcdodds.com/blog/common-mistakes-with-react-testing-library). I would like to suggest a new rule that detects multiple expect inside a wait-for:

❌ // wrong
await waitFor(() => {
  expect(a).toEqual('a')
  expect(b).toEqual('b')
})

✅ // correct
await waitFor(() => expect(a).toEqual('a'))
expect(b).toEqual('b')

[Belco90]

Hey Renato! Thanks for your proposal, it sounds good. Would like to give it a try? PRs are welcome!

[Belco90]

What name do you prefer for this one?

• no-multiple-expect-wait-for
• single-wait-for-assert
• something else

[nickserv]

Maybe no-multiple-assertions-wait-for?

[gndelia]

should we also cover the deprecated methods? like wait and waitForElement?

[Belco90]

I think so. It should be easy after implemented for waitFor right?

[timdeschryver]

While being easy, is it needed?
The linter will fix the deprecated methods to waitFor, and then this rule kicks in.

Just thinking out loud here 😅

[renatoagds]

@Belco90 @gndelia Hey guys! I have been working on this one since few days ago. Sorry for the delay.

I'm calling it no-multiple-expect-wait-for in my branch:

https://github.com/renatoagds/eslint-plugin-testing-library/tree/no-multiple-expect-wait-for

Do I need to stop working on this? Should I rename it?

[gndelia]

oh nono, that's great! Let's continue over your branch. You can continue with it, I can just take another item

We did not know you were at it. Awesome 🚀 🚀

you might want to join the debate here 😄

[renatoagds]

@gndelia Great! Will continue work on this.

you might want to join the debate here

Yes! Sorry for the delay, I read the discussion from #165 to up to date about the directions.

While being easy, is it needed?

@timdeschryver I have mixed feelings about.

Talking about myself, the project that I work are in top of migration for RTL v10 and even with lint fix we have a few points to double check, but we're thinking about use TL eslint to ensure good practices without wait for migration, in this case, could be good to support deprecated methods, but, since it's a opt-in rule, I could only enable it in the final of the migration.

I would suggest to start with waitFor and receive feedback if people are trying to use it with deprecated methods, and implement if necessary.