Skip to content
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 assertion fails, part 3 #7152

Merged
merged 11 commits into from
Dec 28, 2018

Conversation

pedrottimark
Copy link
Contributor

Summary

Delete paraphrased info from value labels which the description line can communicate by formatting.

  • “Expected …” phrase above received value makes me stop and reread every time :(
  • Especially because Expected: and Received: have same length without paraphrased info, display values starting on same line instead of indented on following line.

Will continue in small chunks picking up from #5437 and #5512

After small chunks, matcher name from dim to regular font weight will affect hundreds of snapshots.

Test plan

Updated 33 snapshots.

Examples of baseline and improved reports:

tocontain

Examples of baseline and improved reports with .not notice regular font weight:

not-tocontain

@SimenB SimenB requested review from rickhanlonii and cpojer and removed request for rickhanlonii October 12, 2018 22:58
@rickhanlonii
Copy link
Member

Really like this improvement (especially how it simplifies the mather code)

What happens when the received value is a multiline string? Like a pretty formatted object? My thinking is that we may still want the received value to be on a new line

@rickhanlonii
Copy link
Member

Just realized that the received value can only be an object and we control the printing so nvm

@SimenB
Copy link
Member

SimenB commented Oct 13, 2018

Could we try to align the right side of the colons? VIsual comparison is easier if the line up. Thankfully "received" and "expected" are both 8 characters longs, so it's a matter of padding enough for "value"/"string"/"length"/"array" etc

@pedrottimark
Copy link
Contributor Author

@rickhanlonii Here is picture of multiline string as received value:

tocontain-multiline-string

@SimenB More alignment is more better! I will make a new picture formatted as you suggest.

@pedrottimark
Copy link
Contributor Author

What do y’all think about padding spaces at right of colon to align values:

tocontain-2

@pedrottimark
Copy link
Contributor Author

Before I push changes, I need think more about use cases for getLabelPrinter higher-order function which jest-matcher-utils package will export so people can call it in custom matchers.

Here is code I wrote to make the picture:

type PrintLabel = string => string; // append colon, space, and padding spaces
const getLabelPrinter = (...labels: Array<string>): PrintLabel => {
  const maxLength = Math.max(...labels.map(arg => arg.length));
  return label => `${label}: ${' '.repeat(maxLength - label.length)}`;
};

// in toContainEqual matcher
    const labelExpected = 'Expected value';
    const labelReceived = `Received ${collectionType}`;
    const printLabel = getLabelPrinter(labelExpected, labelReceived);

    const message = () =>
      matcherHint('.toContainEqual', collectionType, 'value', {
        comment,
        isNot: this.isNot,
      }) +
      '\n\n' +
      `${printLabel(labelExpected)}${printExpected(value)}\n` +
      `${printLabel(labelReceived)}${printReceived(collection)}`;

@pedrottimark
Copy link
Contributor Author

pedrottimark commented Oct 15, 2018

Test plan

  • Updated 16 snapshot tests in expect package for aligned value
  • Added 7 tests in jest-matcher-utils package for getLabelPrinter function

@pedrottimark
Copy link
Contributor Author

Received collection type in toHaveLength matcher and updated 10 snapshot tests.

tohavelength-type

@pedrottimark
Copy link
Contributor Author

Aligned values and updated 12 snapshot tests for toBeCloseTo to restart CI honestly :)

tobecloseto

Copy link
Collaborator

@thymikee thymikee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is so good


return (
matcherHint('.toHaveLength', 'received', 'length', {
isNot: this.isNot,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we should make isNot option mandatory, it's too easy to forget.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, while we walk forward by incremental steps, let’s think about end goals for interface.

By the way, it took me a while to understand this.isNot is equivalent to pass for message function: if test passes, print message only if assertion has .not modifier.

But this.isNot property removes [.not] uncertainty in messages about invalid expected or received values. During this pass (pardon pun :) I have been letting marinate in my mind the patterns that we will need to improve those messages.

@codecov-io
Copy link

Codecov Report

Merging #7152 into master will increase coverage by 0.03%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7152      +/-   ##
==========================================
+ Coverage   67.98%   68.01%   +0.03%     
==========================================
  Files         248      248              
  Lines        9476     9487      +11     
  Branches        6        5       -1     
==========================================
+ Hits         6442     6453      +11     
  Misses       3032     3032              
  Partials        2        2
Impacted Files Coverage Δ
packages/jest-matcher-utils/src/index.js 100% <100%> (ø) ⬆️
packages/expect/src/matchers.js 99.41% <100%> (+0.02%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f13b97b...dd45440. Read the comment docs.

@thymikee
Copy link
Collaborator

Let's do it @pedrottimark!

@thymikee thymikee merged commit bf2a42d into jestjs:master Dec 28, 2018
@pedrottimark pedrottimark deleted the improve-report-3 branch December 28, 2018 18:54
captain-yossarian pushed a commit to captain-yossarian/jest that referenced this pull request Jul 18, 2019
* expect: Improve report when assertion fails, part 3

* Display lines of labeled values as two columns with monospace alignment

* Merge and then update CHANGELOG.md

* Add test for getLabelPrinter

* Include received type in label for toHaveLength matcher

* Fix pretty lint error

* Refactor message function in toContain and toContainEqual

* Align values for toBeCloseTo
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants