You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There may be a great reason to not include this, but it feels a bit odd (as I'm starting to write some async test cases) to provide a rejectedWith but not a fulfilledWith.
I understand that I can use .to.eventually.be.fulfilled.and.equal, but I'm wondering -- are:
.to.eventually.be.rejected.and.equal(), and
.to.eventually.be.rejectedWith()
not essentially the same?
If so, I'd think that the fulfilledWith "shortcut" should also be included. If they're not the same, then we can close this request due to my ignorance 😄
The text was updated successfully, but these errors were encountered:
Same here. I was surprised by the lack of "resolvedWith" and "fulfilledWith". But I think the problem is in how we’re should compare a Promise result with the expectation - eq vs eql
seems like a sensible idea to have fulfilledWith. it'd be pretty simple I think compared to rejectedWith since rejectedWith supports passing errors, error constructors, etc. meanwhile, fulfilledWith would literally do the same as an equality check
if either of you want to contribute that, i'd be happy to review
There may be a great reason to not include this, but it feels a bit odd (as I'm starting to write some async test cases) to provide a
rejectedWith
but not afulfilledWith
.I understand that I can use
.to.eventually.be.fulfilled.and.equal
, but I'm wondering -- are:.to.eventually.be.rejected.and.equal()
, and.to.eventually.be.rejectedWith()
not essentially the same?
If so, I'd think that the
fulfilledWith
"shortcut" should also be included. If they're not the same, then we can close this request due to my ignorance 😄The text was updated successfully, but these errors were encountered: