expect: Improve report when matcher fails, part 19 #8367
Conversation
|
Positive assertion omits received value if it is function with prototype:
Positive assertion shows received value otherwise:
Negative assertion omits received constructor name if it is equal:
Negative assertion shows received constructor name otherwise: Updated and added picture according to #8367 (comment)
|
|
Positive assertion shows received constructor name when prop is inconsistent:
Positive assertion shows received constructor name when prop is consistent:
Positive assertion show non-error value instead of constructor name:
Negative assertion omits received constructor name if it is equal when prop is inconsistent:
Negative assertion omits received constructor name if it is equal when prop is consistent:
Negative assertion shows received constructor name otherwise: Updated picture according to #8367 (comment)
|
Codecov Report
@@ Coverage Diff @@
## master #8367 +/- ##
==========================================
+ Coverage 62.29% 62.31% +0.01%
==========================================
Files 266 266
Lines 10729 10737 +8
Branches 2609 2612 +3
==========================================
+ Hits 6684 6691 +7
- Misses 3460 3462 +2
+ Partials 585 584 -1
Continue to review full report at Codecov.
|
| "<dim>expect(</><red>received</><dim>).</>not<dim>.</>toThrowError<dim>(</><green>expected</><dim>)</> | ||
|
|
||
| Expected constructor: not <green>Err</> | ||
| Received constructor: <red>SubErr</> |
There was a problem hiding this comment.
Maybe we should print something for subclasses? It might not always be obvious why this failed if the names look unrelated
There was a problem hiding this comment.
Yeah, it isn’t obvious. Your thoughts how to make it clear are welcome. It reminds me of (positive and negative) assertions for < and so on, where report shows the comparison operator.
There was a problem hiding this comment.
What do you think of this?
There was a problem hiding this comment.
Reminds of the joke:
I’m glad I don’t like X, because if I liked it, I would have to eat it, but I don’t like it!
There was a problem hiding this comment.
What do you think of this?
The idea is super awesome, unfortunately it's not quite correct though, C.prototype instanceof B would be but that's clunky.
What do you think about C extends B?
There was a problem hiding this comment.
Yes, your suggestion is very intuitive!
Do we extend the notation (pardon pun ;) for C extends MiddleClass extends B
There was a problem hiding this comment.
I guess if it's not too much work, why not. Are there many hundred prototypes long chains in the real world? If so, we might need to limit it?
There was a problem hiding this comment.
Here is a compromise that might balance clear and correct without over-explaining:
Expected constructor: not Parent
Received constructor: Child extends Parent
Expected constructor: not Ancestor
Received constructor: Descendant extends … extends Ancestor
There was a problem hiding this comment.
extends ... extends is exactly what I thought of 👌
packages/expect/src/__tests__/__snapshots__/toThrowMatchers.test.js.snap
Show resolved
Hide resolved
|
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
Follow up on residue from #7621 and #8077 according to recent improvements
For
toBeInstanceOfmatcher:Factor out
printConstructorNamesimilar toprintWithTypefunction injest-matcher-utilsFor
toThrow(Constructor)matcher:toBeInstanceOfnameproperty, because it is usually redundant with constructor nameResidue: why TypeScript errors for
received: unknowninprintReceivedConstructorNameTest plan
toBeInstanceOffalsetoBeInstanceOftruetoThrow(Constructor)falsetoThrow(Constructor)trueSee also pictures in following comments.
Example pictures baseline at left and improved at right