Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing promise rejection error code #4532

Closed
franciscop opened this issue Sep 25, 2017 · 8 comments
Closed

Testing promise rejection error code #4532

franciscop opened this issue Sep 25, 2017 · 8 comments

Comments

@franciscop
Copy link

First, I love jest and you guys have made a great work here. In Jest 21.0 .toMatchObject() changed the way it handles Errors. I used to do this in Jest 20-:

const pub = parse(schema, { public: 25 });
await expect(pub).rejects.toMatchObject({ code: 'ERROR_CODE' });

But now I have to pass the same full Error and cannot pass just a part of it. Some times errors are easy and can be built in the spot, but some times they might have more properties. An alternative would be to be able to access the object (error) returned by rejects but as noted here the resolve/reject value cannot be accessed like this with Jest.

This was really useful for testing just the error code, is there an equivalent way of doing this in Jest 21 without writing too much boilerplate? My suggestion: to add a matcher for errors. Something like this:

  • .rejects.withErrorCode()

Or even more generic like this:

  • .rejects.withError({ code: 'ERROR_CODE' })

Or just leave the specific case when there is a plain object being passed to compare by properties instead of by the full thing:

  • .rejects.toMatchObject({ code: 'ERROR_CODE' })

Any of these situations would make IMHO testing for rejection errors much easier. I know that I can write my own extension, but I think testing for rejection error codes should be fairly commonplace. If I am missing something and there is an easy way of testing for rejection codes please let me know.

@franciscop
Copy link
Author

Reference: this was a small workaround for 20- as seen in here: #3601

Now there is no workaround anymore.

@cpojer
Copy link
Member

cpojer commented Dec 16, 2017

I recommend changing your assertions to .toEqual(new Error(…)) instead of just testing for one property.

@cpojer cpojer closed this as completed Dec 16, 2017
@franciscop
Copy link
Author

Those are no plain Errors and I do not have access to the original constructor in the client code, so .toEqual(new ???(…)) is just not possible.

The error instances are generated by sub-libraries that do not expose the constructor. The only assurance is that the error code is that one, and that is the reason for me to test it by one property.

Any recommendation in that situation? I am pretty sure this should be fairly common.

PS, haven't tested it yet but wouldn't the stack trace be different, and so the .toEqual() be always false? I'll test that out later on.

@SimenB
Copy link
Member

SimenB commented Dec 16, 2017

This works:

test('check code property', () => {
  const err = new Error();
  err.code = 404;

  return expect(Promise.reject(err)).rejects.toHaveProperty('code', 404);
});

@guumo
Copy link

guumo commented Jun 24, 2018

@SimenB this example not works:

TypeError: Cannot read property 'toHaveProperty' of undefined

@SimenB
Copy link
Member

SimenB commented Jun 25, 2018

It works: https://repl.it/@SimenB/ComplexGainsboroGnudebugger

You either have a typo or you're on a really old version of Jest

@guumo
Copy link

guumo commented Jun 25, 2018

Ops! my global jest version is 19, now updated and works fine! Thanks :)

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants