-
-
Notifications
You must be signed in to change notification settings - Fork 694
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
Fix 1564 #1566
Fix 1564 #1566
Conversation
my preference would be that an not sure how best to avoid confusion there |
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 agree but I'd add that we should aim for consistency between interfaces.
IMO:
expect(f).to.be.a.function()
/f.should.be.a.function()
/assert.isFunction(f)
should alias acallable()
assert, and so likewisenot.a.function
/isNotFunction
should be an alias for.not.callable()
expect(f).to.be.callable()
/f.should.be.callbable()
/assert.isCallable(f)
should check to see if the object can be called (i.e.typeof f == 'function'
).not.callable
would be!= 'function
.expect(f).to.be.an.async.function()
/f.should.be.an.async.function()
/assert.isAsyncFunction(f)
can checkbe.a('AsyncFunction')
. This means it should be possible to chain.a.callable.async.function()
even if that's redundant. Becausenot
is chainable,assert.isNotAsyncFunction
will only test that its not async, not that it's not callable. So.a.callable.not.async.function()
would pass for regular functions & generator functions, and fail for async functions (generator or otherwise).expect(f).to.be.a.generator.function()
/f.should.be.a.generator.function()
/assert.isGeneratorFunction(f)
can checkbe.a('GeneratorFunction')
, although arguably it should also pass for async generators, as they're still generator functions?- This also means
expect(f).to.be.an.async.generator.function()
/f.should.be.an.async.generator.function()
/assert.isAsyncGeneratorFunction(f)
should work for async generators.
Perhaps the async asserts should check if the stringtag matches /^Async.*Function$/
and the generator asserts should check it matches /GeneratorFunction$/
?
Recently in NodeJS's new One of the points is that a regular Function can return a Promise and thus be used like an AsyncFunction, even though it is not. So, my preference is that |
Yooo! I pushed some changes based off of #1566 (review) for early feedback. Please comment any thoughts (and prayers) if something looks off otherwise I'll continue down this road 😸 |
lib/chai/interface/assert.js
Outdated
@@ -590,6 +591,56 @@ assert.isNotFunction = function (val, msg) { | |||
new Assertion(val, msg, assert.isNotFunction, true).to.not.be.a('function'); | |||
}; | |||
|
|||
/** | |||
* TODO |
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.
TODO
lib/chai/interface/assert.js
Outdated
}; | ||
|
||
/** | ||
* TODO |
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.
TODO
I like the way the code is going and I appreciate your work on this. From my understanding of the code right now, it looks like this in the
So far, to check if an object is an AsyncGeneratorFunction we could test for AsyncFunction and GeneratorFunction. Is this right? If so, I'm in love with it 👍 I believe some tests to ensure the behavior of Also, I am not familiar with the internals of Chai, but does it automatically create the negation of the new assertions, i.e. |
We could add a |
i think it is important we do this part Keith mentioned otherwise, the various places people use e.g. then you would just negate |
Y'all know of a good way to do this that allows us to set the error message to say |
currently we'd do it by if we want to make an actual chain to be or we could just word it more like |
in its current state, looks like you have this:
i do wonder if we are over complicating it. i think i would have:
i think we should just fix up you could argue then we don't need what do you think? sorry for any chaos im causing by picking at this 😂 |
No this is great! I think getting this right is important.
Yeah I think we might be. When in doubt go with the most simple solution so I'm all for it. I'll take a crack at that next. |
I was looking at this and this the tests just fail because we're using
Now we could carve out a exception for functions instead of using |
strange, that isn't what i expected. what leads to it using deep-eql? i thought |
Ah! The chai code can be a bit terse to read sometimes 😅 You're correct! I'll make a push in a minute. |
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 quite a bit smaller PR now I think but might need more tests for the different interfaces.
as far as the interface goes, looks good to me i think. much simpler than introducing brand new chains for each function type IMO be good to get keith's opinion some time though too |
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.
Generally LGTM, but could add a few more tests to prevent future regressions of this type.
Fix #1564 by introducing new
isAsyncFunction
andisNotAsyncFunction
assertions.The thinking is that even though async functions are functions this change will allow for more granular assertions.
I'm still not sure if this is what we'd like though. Async functions are still functions so I could see a argument being made for
isFunction
asserting that a async function is indeed a function. Maybe we should add aisSynchronousFunction
to specifically check if a function is not async and then leaveisFunction
to assert for both sync and async functions?Interested in hearing thoughts.
@43081j @keithamus @ReDemoNBR