-
Notifications
You must be signed in to change notification settings - Fork 29
Make the <function> type a subtype of <object> #448
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
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 usingObject.create(null)
such that their prototype chain is empty?
Yeah, correct 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 💯 greatness.
Looks like this will work if/when we fix and land #328
FIXME:
<function> to (throw|error) <function>