Jest: 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? :smile:

[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.