expect: Improve report when matcher fails, part 17

[pedrottimark]

Summary

For toHaveProperty matcher:

• Display matcher name in regular black instead of dim color
• Display promise rejects or resolves in matcher hint
• Replace obscure pass must be initialized error with expected path must not be an empty array
• 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
• Display unique report for edge case

When positive assertion fails:

• If received path is not complete: Display value of last received property
• If received path is complete: Display either diff (without Difference label) or stringify values, not both

Residue:

• chore to rewrite getPath as iterative algorithm and always return hasEndProp
• possible future breaking change (in Jest 26) to remove the edge case that expected value undefined also matches absence of a property with the key path

Test plan

Snapshots for toHaveProperty

• updated 6 for error
• updated 24 for fail
• updated 23 and added 2 for pass

See also pictures in following comment.

Example pictures baseline at left and improved at right

[pedrottimark]

Negative assertion edge case

The cost of edge case for double meaning of undefined expected value in positive assertion, is Jest got some ’splainin’ to do why the negative assertion must fail

Friendly reviewers, your critique is especially welcome for this message:

Because a positive assertion passes for expected value undefined if the property does not exist, therefore this negative assertion fails unless the property does exist and has a defined value

Show both paths and values:

[pedrottimark]

Negative assertion

Show received value of unexpected property if no expected value:

Omit received value if its serialization is equal to expected value:

Show received value if its serialization is not equal to expected value:

[pedrottimark]

Positive assertion

If it has no expected value, then the received path must be incomplete:

If the received path is empty, display [] even if expected is string, because "" means [""]

If it has expected value, then the received path might be complete:

Note context specific - Expected value because - Expected seemed ambiguous

If it has expected value, then the received path might be incomplete:

This last test represents TDD updated expected path before updating tested code

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