t.throws and t.doesNotThrow should be able to accept a promise

At the moment, t.throws and t.doesNotThrow only accepts a function. It should also be able to accept a promise, like AVA.

I want to be able to test that Koa middleware throws a particular error:

(ctx, next) => {
  t.throws(next(), MyError)
}

It would be great if the function return value and promise resolved value would be returned. Here is an AVA example:

const promise = Promise.reject(new TypeError('🦄'));

test('rejects', async t => {
  const error = await t.throws(promise);
  t.is(error.message, '🦄');
})

[lorenzofox3]

I think you are mislead by console.log. As tests run in parallel, the logging sequence (at least through console.log) is not relevant.

However you should be able to test promise error easily

const throwing = async (message) => {
  throw new Error(message);
}

test('test 1',async t => {
  try {
    await throwing('oh no!');
  } catch (e){
    t.equal(e.message,'oh no!', 'should test the error');
  }
  
  t.ok(true,'shoud run after');
});

or in action

[mindplay-dk]

⚠ warning: the example above will always pass - even if throwing does not throw!

✔ The correct solution was offered in this thread.

I do think we have a problem with this feature… I fall into this trap myself every time - the issue has been posted twice now, and the track record for someone providing the correct workaround is 1:2. 😉

How about the following solution?

1. If the callback passed to throws returns a Promise, it should throw an error and abort the test: this will help folks realize that throws is not intended for use with async callbacks - currently this quietly fails, so this will fix that.

2. Add a another assertion rejected specifically accepting only a Promise, which must be rejected rather than resolved: this is more explicit and makes the distinction more clear.

When failing in throws for passing a Promise, the error message could explain how to correctly switch to rejects, e.g.:

await t.rejected(async () => { .... })

We should tighten the type-hints in TS as well - for throws we can use a param type T extends Promise<unknown> ? never : T, as covered in this article, and for rejected of course this would accept solely a Promise<T>.

(The only remaining pitfall then is people may forget to use await with t.rejected - but that’s just Javascript, I’m afraid.)

What do you think, would you consider reopening this issue?