expect: Highlight substring differences when matcher fails, part 1#8448
expect: Highlight substring differences when matcher fails, part 1#8448pedrottimark merged 16 commits intojestjs:masterfrom
Conversation
|
I am not sure if the Here is 'use strict';
function _defineProperty(obj, key, value) {
if (key in obj) {
Object.defineProperty(obj, key, {
value: value,
enumerable: true,
configurable: true,
writable: true
});
} else {
obj[key] = value;
}
return obj;
} |
|
Oh my god, I'm so excited! 😀
It should be, we had the same thing |
|
Would it make sense for the vendored file to live in |
|
And yes, rendering some explicit newline character would be awesome, like ava does |
Codecov Report
@@ Coverage Diff @@
## master #8448 +/- ##
==========================================
+ Coverage 62.32% 62.78% +0.45%
==========================================
Files 266 267 +1
Lines 10734 11021 +287
Branches 2615 2674 +59
==========================================
+ Hits 6690 6919 +229
- Misses 3461 3497 +36
- Partials 583 605 +22
Continue to review full report at Codecov.
|
|
@SimenB it’s related to your #8085 (comment) although
I think the problem is https://github.com/facebook/jest/blob/master/scripts/build.js#L122-L125
Does it make sense to swap the logic to avoid double negative in if (
micromatch.isMatch(file, JS_FILES_PATTERN) ||
(micromatch.isMatch(file, TS_FILES_PATTERN) &&
!micromatch.isMatch(D_TS_FILES_PATTERN))
) {
// compile file
} else {
// copy file
} |
|
They should work - we deleted some in #8294 which worked fine previously. It's the tsc run that should copy it, not babel. Try to run |
|
Good question about packaging. The reason to keep
|
|
@SimenB this is making me learn more about Jest build scripts and TypeScript config :)
Compiling as |
|
Solved by renaming as
Finding that tricky Question: in |
jeysal
left a comment
There was a problem hiding this comment.
Wooooo, this is super awesome ❤️
Mandatory (TSC won't ever look at the folder if it's not referenced) - if it works without, it's probably "lucky" because it's also referenced from ´jest-diff` |
|
Ah, the way we solved it for Istanbul was a |
|
While writing tests for multi-line strings, I found an edge case of comparison to empty string Highlighting the non-empty string at left seems less helpful than no highlight at right: Added a test and then updated it after adding the missing condition For the test where I found the problem, do you prefer the report at left or right, and why? |
|
I prefer the right one, since it's explicit about the value of "Received". The left one looks like a bug due to it missing received |
Residue
|
jeysal
left a comment
There was a problem hiding this comment.
Still LGTM after the tweaks, feel free to merge if you have nothing more to include here in mind ;)
|
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. |








Summary
Fixes #6881 although space and no-break space still look the same
If positive assertion fails with one-line strings for both expected and received:
Then if character difference with “semantic cleanup” has any common substring:
Display changes similar to Changed Files on GitHub:
Else if no common substring, display without any inverse colors
Build:
EDIT: The following list is generally but not specifically true, because
printDiffOrStringifymoved tojest-matcher-utilspackagepackages/expect/build-es5/index.jsis about 1M bytes, increased < 40K bytesdiff-sequencesdependency, it was already inbuild-es5bundleexpect/tsconfig.jsonsee expect: Highlight substring differences when matcher fails, part 1 #8448 (comment)review ofpackages/expect/src/cleanupSemantic.d.tsis especially welcomesee expect: Highlight substring differences when matcher fails, part 1 #8448 (comment) aboutpackages/expect/build/cleanupSemantic.d.jsLicense:
Does anyone know if I have correctly handled code with Apache License, Version 2.0?
cleanupSemantic.js.eslintignoreand.prettierignorescripts/checkCopyrightHeaders.jsResidue:
toThrow(object)which does not call the same helper functiontoContain,toMatch, ortoThrow[EDIT: and found its effectiveness to be disappointingly hit or miss]Test plan
EDIT: Updated a distantly related snapshot test, see see #8448 (comment)
Existing tests pass, because they have no common substring with “semantic cleanup”
Added 1 snapshot each:
toBeand then added a second test for empty string, see expect: Highlight substring differences when matcher fails, part 1 #8448 (comment)toEqualtoHaveProperty(path, value)toStrictEqualSee also pictures in following comment