Add support for asserting that a promise has resolved or rejected (regardless of value)

[Guardiannw]

Do you want to request a feature or report a bug?
Feature Request

What is the current behavior?
Currently, there is no declarative and easy way to check if a promise resolves or rejects.

What is the expected behavior?
I would like a way to be able to check if a promise resolves or rejects, regardless of the value that it produces, or if it even produces a value, it is irrelevant. In particular, i want to easily be able to easily check to make sure that a promise was not rejected. I don't care at all if it actually sent an error, undefined, or whatever, I just want to make sure it was not rejected. I would like a matcher like expect(promise).toResolve() or expect(promise).not.toReject(). Right now, as far as I can tell, there is no simple way to go about asserting whether or not a promise has resolved or rejected without taking into account its value. I want to be able to assert this without regard to its response, the error message, or otherwise.

Please provide your exact Jest configuration and mention your Jest, node,
yarn/npm version and operating system.
Jest version 22.0.4

[thymikee]

How about http://facebook.github.io/jest/docs/en/expect.html#resolves

[SimenB]

Does resolves.toBe(expect.anything()) work? Still a bit verbose either way, I guess

[Guardiannw]

No, it doesn't work. expect.anything() doesn't cover the situation when it is null or undefined. Also, the .resolves does not work because it requires a matcher on the end of it. There doesn't seem to be a simple way just to check to make sure it was resolved or rejected.

[Guardiannw]

Hey @SimenB, is there any update on this?

Thanks!

[SimenB]

We've landed support for asynchronous matchers, so you can add a toResolve or toReject yourself if you want 🙂 See #5919 (available in jest@beta)

@mattphillips something for jest-extended?

Closing as I think it can be solved in user land. Happy to reopen if proven wrong

[mattphillips]

@Guardiannw I like this! Mind opening this up in jest-extended and I’ll help get this working in user land when Jest@23 lands? 😄

[Guardiannw]

@mattphillips Will do! Thanks!

[slifty]

Just a note that I would find this useful!

My use case is that I am testing an abstract class and I want to be able to test that async methods that have been overridden will properly resolve in the context of the parent objects that call them.

[ysfaran]

For anyone who wants a simple solution for asserting promise resolution or rejection:

extendExpect.js

async function toReject(promise) {
  let rejected
  try {
    await promise
    rejected = false
  } catch {
    rejected = true
  }

  return {
    pass: rejected,
    message: () => `expected promise to ${rejected ? "resolve" : "reject"}`,
  }
}

async function toResolve(promise) {
  let resolved
  try {
    await promise
    resolved = true
  } catch {
    resolved = false
  }

  return {
    pass: resolved,
    message: () => `expected promise to ${resolved ? "reject" : "resolve"}`,
  }
}

expect.extend({
  toReject,
  toResolve,
})

Add setup file to your jest config:

jest.config.js

module.exports = {
  // ...
  setupFilesAfterEnv: ["<rootDir>/setupTests.js"],
}

Import extendsExpect file in your setup file:

setupTests.js

import "./extendExpect"

Usage:

expect(promise).toResolve()
expect(promise).toReject()

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.