expect: Improve report when matcher fails, part 15

[pedrottimark]

Summary

For toBe matcher:

• Display matcher name in regular black instead of dim color
• Display promise rejects or resolves in matcher hint
• Omit redundant or irrelevant information, as described below

When negative assertion fails:

• Display not between expected label and value
• Omit received value because it is redundant

When positive assertion fails:

• Display either diff (without Difference label) or Expected/Received values, not both
• Display either Difference or message about deep equality independent of the above , not both
• Display Received value has no visual difference in black instead of dim
• Display If the test should pass with deep equality, replace toBe with ${deepEqualityName} to emphasize toStrictEqual more than toEqual matcher

@jeysal your work on shouldPrintDiff in #7605 gave me important example for the logic :)

Residue: pretty-format serializes [, 1] and [undefined, 1] the same (it would be a breaking change to fix for sparse arrays, but it is an example for improvement via data-driven diff)

Test plan

• Updated 18 snapshot tests
• Added 7 9 snapshot tests

Friendly reviewers, you have my apology for mess of some added and updated snapshots :(

See also pictures in following comments with baseline at left and improved at right

[pedrottimark]

Received value is redundant in negative assertion of referential identity:

Display difference if it is relevant:

[pedrottimark]

Display message about no visual difference without irrelevant Difference label:

[pedrottimark]

See #8281 (comment) instead of this comment

Your critique and improvement of the proposed message is welcome:

• If the testit should pass with deep equality, replace toBe with toStrictEqual
• If the testit should pass with deep equality, replace toBe with toEqual

Rewrite message not to mislead for expected failures during first phase of TDD and to emphasize toStrictEqual more than toEqual matcher, sorry about ruthless cropping at left edge of pictures:

If referential identity test fails and deep equality test would pass, is it okay to omit the diff?

[pedrottimark]

Display primitive as Expected/Received values:

Different types:

At least one string is not multiline:

Specific other types:

[jeysal]

This output is a lot smarter, thanks @pedrottimark.
I love the part about trying toStrictEqual and then toEqual to suggest what's likely the better fit.

[jeysal]

Can you explain why the checks on this line are necessary and why deepEqualityName affects difference a few lines below? I'm probably missing something, I don't quite understand why the logic needs to be this complex.

[pedrottimark]

Renamed isShallowInequality and refactored assignments to deepEqualityName

Your intuition was correct that difference was too complex.

I moved the message below hint and above difference or Expected/Received lines.

[jeysal]

Cool, now the deepEqualityName and difference concerns are nicely separated. I've just tried it locally and it looks like you can also remove the deepEqualityName conditions? At least it doesn't seem to fail any test.

-          if (!isShallowInequality) {
-            if (expectedType === 'object' || expectedType === 'array') {

[pedrottimark]

Yes indeed, thank you for patient critique!

• For deepEqualityName the only if condition is skip map and set until we review the current questionable logic
• Separate and rename hasConciseReport to make its purpose clear to short-circuit a line diff (while we improve the remaining matchers, we will discover whether it is reusable)
• Added condition and 2 snapshot tests for deep equal and unequal dates

[pedrottimark]

Updated pictures supersede #8281 (comment) and illustrate #8281 (comment)

[thymikee]

👍

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