-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
What names should Assert-Throw parameters have? #13
Comments
Looking at it I think I like A better. I also start thinking that renaming -Message to |
Settling down to: { throw "some exception" } | Assert-Throw `
-ExceptionType ([Exception]) `
-ExceptionMessage '*some*' `
-FullyQualifiedErrorId '*abc*' `
-AssertionMessage 'custom message for the assertion' |
I wonder if the the confusion of #24 could have been avoided if How do you feel about |
@alx9r I get your confusion, |
At the moment it is |
I think it would be useful for
Assert-Throw
to provide parameters that would filter exceptions based on Message, Type and FullyQualifiedErrorId, but I cannot decide how to call those parameters.At the moment I am using ExceptionMessage (because Message is taken for custom assertion message). Should I use
ExceptionMessage
for the parameter name?Should I rename
Message
on every assertion toAssertionMessage
and useMessage
instead?The most common case is that you are simply expecting any exception. The parameter could be called
Expected
but I would rather call itType
. The complication here is that you mostly get ErrorRecords not Exceptions directly and so the type of the incoming object is not what you are asserting on, instead you often need to extract the exception from the error record and soExceptionType
seems more appropriate.the input to the assertion is a script block, and often those are called simply
ScriptBlock
, I could call itActual
but that would imply that I am expecting some value, which is not correct.All in all there are basically those two forms I am deciding between:
Which one do you like more and why? Is there a third, better option?
The text was updated successfully, but these errors were encountered: