Fix pretty print for closeTo matcher

[L4vlet]

Summary

This PR fixes print for the closeTo matcher. Currently, it breaks with the val.toAsymmetricMatcher is not a function error.

Test plan

• Ran yarn test. Everything passed except for two tests related to Mercurial. They were as well failing on my machine before I made any changes
• Wrote two additional unit-tests using objectContaining as an example

[mrazauskas]

Good catch.

It could be good to add a test case without precision arg: expect.closeTo(4.23). And perhaps an edge case with Infinity and something like this as well: expect.closeTo(1.56e-3, 4).

Another though. If I get it right, Expected: NumberCloseTo 0.2345 (2 digit) means that a number close to 0.23 was expected? Wouldn’t it be enough to print: Expected: NumberCloseTo 0.23? Or something like: Expected: Number 0.23 ± 0.005?

[L4vlet]

Good note. Thank you. I've added more tests (infinity, scientific notation and without precision).

Regarding print format, I don't think it's a good idea to use the format you've suggested.

1. We'll have to bring rounding code to the serialize function to correctly display an expected number
2. We'll change the display of the input user has put into their tests (in comparison with their code) which may lead to a confusion

However, I'm not sure about my version either. I'd be glad to see any other proposals.

[SimenB]

Any particular reason why we cannot implement toAsymmetricMatcher on https://github.com/facebook/jest/blob/b82fd89d16fdbe74d9bc80dd86ae4912966adc1d/packages/expect/src/asymmetricMatchers.ts#L293? Instead of adding to pretty-format. Same for the existent types.

Also, we should throw a more useful error if toAsymmetricMatcher is not present - it's optional: https://github.com/facebook/jest/blob/b82fd89d16fdbe74d9bc80dd86ae4912966adc1d/packages/expect/src/asymmetricMatchers.ts#L84

---

I don't have strong opinions about the exact message when serialized btw, I think the current one seems fine?

[SimenB]

ping @L4vlet 🙂

[L4vlet]

Hey, thank you for the ping. Got a bit busy.

I am not sure about the reasons why .toAsymmetricMatcher has not been implemented before. I am not that familiar with the internals yet. Let me try to check if there was a reason for that

[L4vlet]

Any particular reason why we cannot implement toAsymmetricMatcher on ... ? Instead of adding to pretty-format. Same for the existent types.

If I got it right, originally (PR) it was implemented that way. However, later author decided to create a plugin for the pretty-print to

• remove complex printing code
• support various client settings (spaces, identation and so on) which makes sense for complex structures (Arrays, Objects)

In our case, it's not that necessary as printing is relatively simple. We can put it inside .toAssymetricMatcher as we do for the Any matcher.

Also, we should throw a more useful error if toAsymmetricMatcher is not present - it's optional:

I suggest we write a test which will check all matchers to see if jest can correctly print them. Not sure about the special error handling, though. It is not a kind of error client can fix by themselves so there won't be much use from a pretty message.

[SimenB]

Error handling would be Asymmetric matcher *name* does not implement `toAsymmetricMatcher` instead of val.toAsymmetricMatcher is not a function

[L4vlet]

@SimenB, good time of the day. Could you take a look again, please? I've moved the formatting from pretty-print to class function and added error handling.

As for the test I was going to write, I couldn't find a proper way to extract all AsymmetricMatcher-s from the expect object. Maybe you have an idea of how to do that?

[SimenB]

Thanks!

[SimenB]

https://github.com/facebook/jest/releases/tag/v28.0.0-alpha.9

[github-actions]

This pull request 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.