fix: throw an error and a warning if .poll, .element, .rejects/.resolves, and locator.* weren't awaited

[sheremet-va]

Description

If expect.poll().to* or expect.element().to* is not awaited, the test will now fail. The stack trace leads to the line where it's called. The callback to .poll will never be called to avoid unhandled rejections.

If expect.rejects/expect.resolves was not awaited, Vitest will print a warning:

If async locator.* methods are not awaited, Vitest will fail the test. The RPC will never be called to avoid unhandled rejections:

TODO:

• Test
• Docs update

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[sheremet-va]

@hi-ogawa this was pretty easy to do 😄

[netlify]

✅ Deploy Preview for vitest-dev ready!

Name	Link
🔨 Latest commit	6a2b63d
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/672e151f1026f60008316111
😎 Deploy Preview	https://deploy-preview-6877--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Smrtnyk]

I was bitten by this many times 😓
good stuff to have this

[sheremet-va]

@hi-ogawa @AriPerkkio should we do the same with .resolves and .rejects? 🤔

[hi-ogawa]

Looks good to me 👍
One caveat is that it's not a genuine promise tracker, so something like these get through.

test('repro', async () => {
  myPollWrapper();

  Promise.all([
    expect.poll(() => 3).toBe(4),
    expect.poll(() => 3).toBe(4),
  ]);
})

async function myPollWrapper() {
  await expect.poll(() => 3).toBe(4);
}

But these are only false-negative of some edge cases and I don't see any false-positive, so this should be a nice improvement.

[AriPerkkio]

Looks good! Showing the erroneous line is really nice dx improvement. 💯

should we do the same with .resolves and .rejects?

Sure why not. I'm not familiar with internals of expect, but could this be done on any higher level instead of patching all matchers?

[hi-ogawa]

should we do the same with .resolves and .rejects? 🤔

Does this means we remove recordAsyncExpect trick for auto await? I would prefer the change as it would be more well-defined behaviors for users. I guess technically that would be breaking change though.

[sheremet-va]

should we do the same with .resolves and .rejects? 🤔

Does this means we remove recordAsyncExpect trick for auto await? I would prefer the change as it would be more well-defined behaviors for users. I guess technically that would be breaking change though.

Hm, I am not sure what is better 🤔 I like to be stricter, but I don't know if we can enforce it now 🤔 The expect.resolves basically implicitly becomes expect.soft.resolves right now, and it's documented

[sheremet-va]

I think maybe we should also throw an error or show a warning if locator methods were not awaited:

getByRole('button').click()
expect(button).toHaveText('123')

React shows a warning if React.act wasn't called, and we can maybe do the same instead of failing the test 🤔 (But since we know what test caused it, we can also force it to fail which might be better)

What do you think?