Suggest new assertions on async rejection

[3cp]

Following up #472 (comment)

Suggest to add the two assertions (or something similar) from tape-promise https://github.com/jprichardson/tape-promise#new-assertions

It would not change the existing behaviour, as the two assertions are async.

Example from tape-promise:

test('reject and doesNotReject example', async (t) => {
  await t.rejects(asyncFunction)
  await t.rejects(asyncFunction())
  await t.doesNotReject(Promise.resolve())
})

The await is on the assertion, not on the input of the assertion. It reads "The input promise will eventually reject".

Right now I am using following code to migrate from tape-promise to tape v5.

test('...', async t => {

  try {
    await something();
    t.fail('should not pass');
  } catch (err) {
    t.ok(err instanceof SomeErrorType);
  }
});

[ljharb]

This only works if you await it. Additionally, tape works with any promise-returning test function.

node itself has issues with their promise assertion helpers, namely that they need to force an await for work properly, but there's no wait to do that.

What I would suggest is using normal promises:

return something().then(result => { throw result; }, err => err) which will "invert" the promise.

[3cp]

Oh, I see your point. Thx.

[ljharb]

To be clear; node's assert has rejects and doesNotReject, so that's the primary motivation to add it.

The problem (one which node itself also has) is, what do you do if someone does t.rejects(Promise.reject()), and doesn't await that value? Unhandled rejections in the language are perfectly fine, but you do not want those in your tests.

[Raynos]

@ljharb

Can you return a thenable from t.rejects that checks to see if someone called then() in nextTick() and if not add a failure like "double end" or "forgot to call end" to the TAP output ?

[ljharb]

The user can do that - the problem is that tape can’t force the user to do so.

Calling t.rejects in a test suddenly making the test wait on a promise sounds very strange to me, and we’d have to do some pretty complex acrobatics to combine multiple rejects/doesNotReject promise with the final promise the user may or may not return, including those of subtests.

[ljharb]

also, nextTick isn’t soon enough; the test promise might take many ticks to settle.

[Raynos]

I guess I am saying what if t.rejects requires await t.rejects as part of the public interface.

Basically make it return a BlockingThenable and tell the user dude you did not await t.rejects

Maybe that's not better, maybe that's worse. But it's an option.

[ljharb]

I guess I'm still not clear on what that would mean, a "blocking thenable". Even if we could detect the "fail" case (where the promise does not reject) when the test ends, we couldn't detect the "succeed" case (where the promise does reject).

[3cp]

I have been hurt by forgetting await before t.rejects.

Also I need to explain to co-worker why t.rejects(await someAsync()) doesn't work.

Appreciate if the tool can point out the direction in error message, which is probably the best we can do here, if it's possible.

[ljharb]

If node is incapable of improving the experience here, I'm not sure how we can :-/

[fregante]

Also I need to explain to co-worker why t.rejects(await someAsync()) doesn't work.

That is no different from:

t.rejects(someSync())
console.log(throws())
window.addEventListener('load', onload()) // <-- notice it's called

While they're annoying, they're entry-level errors and there's nothing the engine or other tools can do (except TypeScript in some cases).

As far as Tape or Node is concerned, that line of code isn't any different from

const v = await someAsync();
t.rejects(v)

or just

throw new Error();
t.rejects(v)