Assert that async expects are awaited or returned

[SimenB]

valid-expect should check that if there's a rejects or resolves on an expect, that it's either awaited or returned.

Example where we should warn:

test('some test', () => {
  expect(Promise.resolve('hello')).resolves.toBe('hello');
});

[macklinu]

I'm going to give this one a try today.

[macklinu]

A question about await syntax - is this valid?

test('some test', async () => {
  expect(await Promise.resolve('hello')).resolves.toBe('hello');
});

[SimenB]

is this valid?

Nope, correct there is no resolves as it's already awaited

[macklinu]

I closed #78 - this is open for someone to give another shot at resolving this issue. 👍

[callumlocke]

This would be a great feature, would have saved me a lot of mistakes today.

It would be nice if it could also be configurable, to enforce one or the other syntax:

// return
test('some test', () =>
  expect(Promise.resolve('hello')).resolves.toBe('hello');
);

// async/await
test('some test', async () => {
  await expect(Promise.resolve('hello')).resolves.toBe('hello');
});

Personally I would want to configure it to allow only await (even in functions with just a single assertion) because it's more explicit. With implicit return it's more likely someone (me) might come along later and add braces in order to add a second assertion, and inadvertently break it.

[SimenB]

I agree it would be best if we could enforce await over .then or returning the promise

[SimenB]

🎉 This issue has been resolved in version 22.12.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀