expect: Improve report when matcher fails, part 16

[pedrottimark]

Summary

For toEqual and toStrictEqual matcher:

• Display matcher name in regular black instead of dim color
• Display promise rejects or resolves in matcher hint
• Display // deep equality in dim color at end of matcher hint
• Omit redundant or distracting information, as described below

When negative assertion fails:

• Display not between expected label and value
• Display received value only if it has different serialization

When positive assertion fails:

• Display either diff (without Difference label) or Expected/Received values, not both
• Display Received: has same serialization instead of redundant value

Moved code added in #8281 from toBe matcher to print.ts file and edit message string

@jeysal after we have improved reports for all matchers, let’s discuss whether to move the additional logic in shouldPrintDiff to jest-matcher-utils package

Two positive reports changed from diff to Expected/Received:

• strings which are not both multi-line
• received array and expected asymmetric matcher do not have same getType value

Residue: stringify (that is, pretty-format with min option)

• omits constructor name for array or object, so in edge case of received value constructed from different class than expected value, it should have a different serialization
• which is especially confusing for Number(0) and String('abc')

Test plan

Updated snapshots:

	file	matcher
4	expect extend	toEqual	positive	hint
2	e2e failures	toEqual	positive	hint including rejects and resolves
1	jest-matcher-utils index	toEqual	positive	hint
5	expect matchers	toBe	positive	display Received: has same serialization
42	expect matchers	toEqual	positive	remove Difference and display Received: has same serialization
48	expect matchers	toEqual	negative	omit redundant Received value
1	expect matchers	toStrictEqual	positive	remove Difference
1	expect matchers	toStrictEqual	negative	omit redundant Received value

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

[pedrottimark]

For negative toEqual when received value has different serialization:

For negative toEqual when received value has same serialization:

For positive toEqual when received value has different serialization:

For positive toEqual when received value has same serialization:

For positive toBe when received value has same serialization:

For positive toEqual which has diff:

For positive toStrictEqual which has diff:

[SimenB]

Oh yeah! Especially the "not" changes are sweet

[SimenB]

"serialises to the same string"?

[pedrottimark]

Yes, let’s prefer a verb to a noun. What do you think about the following:

Expected: []
Received: different instance that serializes to the same string

And this reminds me to think about a sentence for toEqual and toStrictEqual in ExpectAPI.md to explain that different functions are not deep equal, see #8166

[pedrottimark]

I decided on the shorter statement suggested by Simen.

The called function cannot assume that the longer statement is true.

[scotthovestadt]

if this is merged soon it can go into the next release :)

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