feat(valid-expect): warn on await expect() with no assertions

[motiz88]

Makes the following an error under the valid-expect rule:

await expect('something'); // No assertion was called on expect().

Rationale

As this plugin already has a rule for expect-with-no-assertions, I thought I'd add a similar one for await expect.

Speaking from recent experience, the simple mistake of awaiting the wrong thing (await expect('something') instead of await 'something') can be a pain to track down and fix, as its effects are likely to be felt far from the line containing the actual mistake (which itself will never throw at runtime).

[G-Rath]

Looks good to me!

It's interesting that it doesn't already pick this up since I would have figured it'd be reported, but apparently not 🤷‍♀

I've left two comments that are not blocking, but would be cool if you wouldn't mind addressing 🙂
(I'll merge in a bit, just to give you some time to see this)

[motiz88]

It's interesting that it doesn't already pick this up

There might be a case for inverting the check on the parent node altogether. What if we made it so expect() had to be the object of a MemberExpression, and anything else would error with noAssertions?

Is the following a common/allowed pattern at all? (And if so, how do we feel about forbidding it?)

const ex = expect(fooBar());
ex.toBe(true);
ex.not.toBe(false);
// etc

This doesn't have to block this PR. Just curious :)

[G-Rath]

Is the following a common/allowed pattern at all? (And if so, how do we feel about forbidding it?)
What if we made it so expect() had to be the object of a MemberExpression, and anything else would error with noAssertions?

That's an interesting thought, which I will think on over the holidays.

When I converted this plugin to TypeScript, I looked into exactly that sort of thing, and my conclusion was that there is a fine balance to try and strike w/ AST handling, as so to support generally as much as possible w/o being too open ended that you need to do a whole bunch of checks anytime you want to sneeze.

I don't think that change would be a big win for us, as it's not something we've got lots of bugs on (that I know of?), but I'll have a think on it b/c it is an interesting thought.

[github-actions]

🎉 This PR is included in version 23.2.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀