-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
expect: Improve report when matcher fails, part 7 #7866
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking sharp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, this is awesome!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great that we found a format we're both happy with 👍
Finally catching up, this pull request provides concise solution to problem reported in #7105 |
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. |
Summary
For 4 matchers which correspond to
>
,>=
,<
,<=
number comparison operators:not
and operator followingExpected:
labelFor more information, see discussion with @jeysal in #7795
For these matchers which define expected intervals, I have not thought of any additional way to reduce apparent weirdness when received value is equal to expected boundary.
Residue for future pull request, in call to
ensureNumbers
helper function:options
as argument to displaypromise
andisNot
Test plan
Updated 66 snapshots. To save mental effort, review as 33 adjacent pairs of snapshots.
toBeGreaterThan
toBeGreaterThanOrEqual
toBeLessThan
toBeLessThanOrEqual
Here are pictures for 2 out of 4 matchers: