unexpected
unexpected copied to clipboard
unexpectedjs
Alias 'to throw' as 'to throw ... satisfying'
Aliases for "to throw" are already supported - see the documentation for the assertion here.
The word "satisfying" is not something defined for "to throw", but if we added it that wouldn't really be an alias but an entirely different assertion. However, you can already achieve exactly the semantics you want by using expect.it, for example:
expect(() => { throw new Error() }, 'to throw', expect.it('to have property', 'message'));
expect(() => { throw new Error() }, 'to throw error', expect.it('to have property', 'message'));
expect(() => { throw new Error() }, 'to throw exception', expect.it('to have property', 'message'));
The to throw... assertion already uses "to satisfy" semantics, though? In the light of that I think it would make sense to add the ...satisfying variant as an alias?
My apologies, I think I misread the
The issue title was also a bit confusing, I've updated it to make it a bit clearer. While I have your attention, what does <function> to throw (a|an) <function> do :)? https://github.com/unexpectedjs/unexpected/blob/9b30831c8365a531dce26af401ca5ebdc5d5fb7c/lib/assertions.js#L1030-L1044
I've been thinking about this some more - I can definitely see the value in this alias but I'd like to raise one concern.
Using satisfying here would introduce something that behaves a little differently than for example "to have an item satisfying" primarily because of the matching of the error message to a string of its supplied. That would make this use of "satisfying" a little different to all the others. My concern is also that since (unfortunately) strings can be thrown at the language level this would create an annoying ambibugity. I might be over losing this though so keen to hear thoughts.
@joelmukuthu thanks for expanding on the description a bit :)
@alexjeffburke I agree, but I've also always thought of to satisfy as an assertion that allows you to assert against different types which to me makes this an acceptable ambiguity aka "it's a feature" :D. Actually I think to throw error satisfying <string> reads better than to throw error <string>
I agree about to throw error satisfying <string> reading better. And to throw error satisfying <object> even more so!
<function> to throw (a|an) <function> checks that the thrown value is an instance of a particular class, eg.:
expect(myFunction, 'to throw an', httpErrors.Conflict);
Agreed about that spelling for which I think means we've reached some broad agreement - I can have a look next time I'm near core.
the assertion does something a little special for strings I believe (comparing the message against it)
You're right, that's a bit of a wart in itself, but I think we can fix that so it reduces directly to <UnexpectedError> to satisfy...: #538.
@joelmukuthu, personally I'd welcome a PR for this now that the other oddity got resolved.