Make the <function> type a subtype of <object> - #448
Conversation
02fc5df to
ca9c8b7
Compare
…ny|Error> to [exhaustively] satisfy <function> assertion, which probably shouldn't even be there
…ction> assertions in one case
1 failing:
1) to satisfy assertion
should render a diff when the function differs:
5 failing:
1) to satisfy assertion
forwards normal errors to the top-level:
2) to satisfy assertion
should render a diff when the function differs:
3) to satisfy assertion
should not break when the assertion fails and the subject has a property that also exists on Object.prototype:
4) to satisfy assertion
with the not flag
should fail when a non-Unexpected error occurs:
5) to satisfy assertion
on Error instances
when satisfying against a function
fails when the function throws:
4 failing:
1) to satisfy assertion
forwards normal errors to the top-level:
2) to satisfy assertion
should render a diff when the function differs:
3) to satisfy assertion
should not break when the assertion fails and the subject has a property that also exists on Object.prototype:
4) to satisfy assertion
on Error instances
when satisfying against a function
fails when the function throws:
3 failing:
1) to satisfy assertion
should render a diff when the function differs:
2) to satisfy assertion
should not break when the assertion fails and the subject has a property that also exists on Object.prototype:
3) to satisfy assertion
on Error instances
when satisfying against a function
fails when the function throws:
7 failing:
1) to satisfy assertion
should render a diff when the function differs:
2) to satisfy assertion
should not break when the assertion fails and the subject has a property that also exists on Object.prototype:
3) to satisfy assertion (NEW!)
on Error instances
when satisfying against a function
should succeed if the function does not throw:
4) to satisfy assertion
on Error instances
when satisfying against a function
fails when the function throws:
5) to satisfy assertion (NEW!)
on Buffer instances
should satisfy a function:
6) to throw assertion (NEW!)
given a function the function is called with the exception:
7) when passed as parameters to assertion (NEW!)
with the constructor flag
should create a new instance:
Should have been removed in #328
|
I got this to work now, but it involved:
Along the same lines it removes the I can try to pick these apart if it's mixing too many things together. Also, we could consider alternatives to the addition of the ... And some more tests would be nice, I guess. |
|
I tried and failed to split this up into chunks, but added some tests now :) |
da89eab to
58be731
Compare
|
The coverage drop in assertions.js and types.js is due to covered lines being removed, no new uncovered lines are being introduced. |
alexjeffburke
left a comment
alexjeffburke
left a comment
There was a problem hiding this comment.
This is looking seriously good - have added one comment to the "to satisfy" change.
Seeing all the test suite changes together make it very clear that this change together with the previous expect.it() stuff make things far more consistent. Specifically banning the problematic "to satisfy " case is excellent, and since we spoke of a conversion guide we could easily spit out a URL to a page that describes this stuff if need be.
| return key in obj; | ||
| hasKey(obj, key, own) { | ||
| if (own) { | ||
| return Object.prototype.hasOwnProperty.call(obj, key); |
There was a problem hiding this comment.
Just to be clear, I guess the use of hasOwnProperty from the Object is to avoid having any problems with objects that might have been created using Object.create(null) such that their prototype chain is empty?
I'm trying to find points of reference for this new own situation - I guess it's a consequence of getting literally all the possible property names. I've got this niggling feeling tat this conditional should be contained entirely within "to satisfy" rather than end up in hasKey, but I cannot yet figure out why yet..
There was a problem hiding this comment.
Just to be clear, I guess the use of hasOwnProperty from the
Objectis to avoid having any problems with objects that might have been created usingObject.create(null)such that their prototype chain is empty?
Yeah, correct 👍
There was a problem hiding this comment.
I've got this niggling feeling tat this conditional should be contained entirely within "to satisfy" rather than end up in
hasKey
Yeah, I feel the same way. All the valueType stuff that has to do with satisfying against a subtype of object is a bit weird, maybe we don't actually want it.
…hat should have been changed in #328
…ssage is more precise
…sWithFunction Feature/unsupport to have items with function
* v11: Paralellize the Travis build, by splitting the main target Increase the Karma timeout to 1 minute Stop testing jest on all Node versions Updated the changelog 10.40.0 Build unexpected.js Specify Node version numbers as strings instead of floats Added BrowserStack badges Fix IE tests and remove special casing for PhantomJS Don't run the IE11 browser tests in the Chrome headless build No need to build with 8.4.0 twice Update build matrix, run browser tests separately Update rollup to version 0.68.1 Initial browser stack setup Use the progress reporter for karma Added karma, mocha, chrome headless setup Update rollup-plugin-node-resolve to version 4.0.0 Fix special casing of UnexpectedError in <function> to error/throw
3 participants
Looks like this will work if/when we fix and land #328
FIXME:
<function> to (throw|error) <function>