Do not highlight passing asymmetric matchers in diffs

[MarkyMarkMcDonald]

🚀 Feature Proposal

This is another idea related to more helpful failure diffs in the same vein as #6170.
The diff of a failing expectation currently highlights nested usages of expect.objectContaining and expect.anything because they are not "equal" to whatever was received. I propose only printing out a diff if the matcher fails.

Motivation

Both this issue and #6170 are the product of a pairing session where we had a hard time tracking down what the actual error was when an existing test started failing. I think that test could have been broken up into several more specific tests or used chained expectations, but it would have been nice to pinpoint the failing property right away.

Example

Here's an example of a failing test that uses a combination of matchers:

https://repl.it/repls/DifficultSvelteMonitors

The only property that doesn't match is "rank" due to a type mismatch, but it's hard to see that when scanning the failure diff because the nested matchers are displaying.

The desired approach would look like this:

Pitch

Why does this feature belong in the Jest core platform?

This is a change to the default reporter that will help identify the cause of failures faster.

[rickhanlonii]

Oh this is great, so basically when doing the diff, also compare the asymmetric matchers

What do you think @pedrottimark?

[pedrottimark]

Yes, serialize-then-diff is barrier to solve some obvious problems. See also #7027

This has been in my slow cooker for a while with limited progress. Happy to hear your thoughts.

[grosto]

This one sounds like fun. I can give it a try if nobody is actively working on it.

[pedrottimark]

@grosto Super! As a first step, so we can discuss what a solution looks like independent of how to achieve it, can you and anyone else subscribed to this issue either:

• identify existing tests which display confusing diff when they fail
• develop some baseline tests to illustrate problems

Tomorrow I will share some thoughts about what and how for you to critique.

[jeysal]

Well the minimal one is

expect({
  a: 'a',
  b: 'b',
}).toEqual({
  a: 'x',
  b: expect.any(String),
})

[grosto]

@pedrottimark Sounds great!

I am a bit busy for the next 2-3 days. As soon as I find the time, I will make a PR with simple tests which demonstrate the current diff issues.

[markmsmith]

I can offer another use case in support of the output being more specific.
When using expect.objectContaining it can be really hard to see what's changed when the structure is really large, such as when checking the headers of a Restify Request or Response object.
It would be much easier to see the mismatch if the output only printed the fields that you're attempting to partially match on.
For example:

 expect(myFnSpy).toHaveBeenLastCalledWith(
  expect.objectContaining({
    env: 'test',
    req: expect.objectContaining({
      method: 'POST',
      headers: expect.objectContaining({
        'x-amzn-trace-id': expect.any(String),
        'x-forwarded-proto': 'https',
        'x-forwarded-for': 'some_client_ip'
      })
    })
  })
);

[github-actions]

This issue 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.