v5 vs chai-as-promised

[mykola-mokhnach]

Hello,

Thanks for working on this great library.

This is not an issue, but rather a request for an advice. In the Appium project we have a large tests codebase where we use both chai and chai-as-promised modules to simplify promises validation. The latter is obviously not compatible with v5 of chai, so we would like to ask your advice there. Do you have an official tutorial/approach for chai v5 to test promises like chai-as-promised could, so the latter may be eventually dropped, and we could only rely on the "raw" chai implementation? Or maybe there is some chai technique/plugin we don't know about, which could help us to resolve the above compatibility issue? Or should we report a feature request to chai-as-promised and postpone the chai bump until it is resolved?

[keithamus]

I would use async/await to unbox promises and test their underlying values or side effects.

[mykola-mokhnach]

thanks for your response. This might be a solution, although it would require to update a lot of the existing code. For example we'd have to change all occurrences of await promise.should.be.rejected to assert.throws(() -> await promise, Error). Maybe there is some way to hack this approach in order to reduce the necessary amount of changes?

[43081j]

afaik throws won't await the function you give it either, so i suppose you'd have to try/catch it yourself right now.

chai-as-promised doesn't seem very active. i wonder if it may be worth us some day adding more support for async stuff here at least

[birtles]

I found it easiest to use promise.catch((e) => e) to return the rejected value for testing.

For example:

// Before
await assert.isRejected(update, AbortError);

// After
assert.instanceOf(await update.catch((e) => e), AbortError);

// Before
await assert.isRejected(update, /aborted/);

// After
assert.match((await update.catch((e) => e))?.message, /aborted/);

// Before
await Promise.all([
  assert.isRejected(firstUpdate, AbortError),
  secondUpdate,
]);

// After
const [firstUpdateResult] = await Promise.all([
  firstUpdate.catch((e) => e),
  secondUpdate,
]);
assert.instanceOf(firstUpdateResult, AbortError);

[ethanresnick]

The catch trick @birtles showed isn't a bad solution, but it's still technically possible for the test to pass if the promise doesn't reject (and just happens to fulfill with a value that also matches the assertion).

Maybe more realistically, if you don't care about testing the rejection value — you just want to assert that the promise rejected — then you have to make up some value to return from the .catch() that you know won't collide with any value the promise could fulfill with, or you have to do something like:

await update.then(() => {
  throw new Error("should have rejected!");
}, (_e) => {
  // swallow error since we expect a rejection
});

which I imagine many readers would find a bit unintuitive.

I think it'd be much better for chai to have some built-in assertions around promises. E.g., expect(update).toReject() or expect(update).toReject(AbortError). These assertions would end up themselves returning promises, so the calls would be awaited, I suppose: await expect(update).toReject().