-
-
Notifications
You must be signed in to change notification settings - Fork 476
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
Should-Throw
: It is not possible using positional parameters when also using pipeline input
#2527
Comments
Thanks for feedback. Will have to look into the positional arguments compared to v5 behavior. |
Yeah I think this is the closest we can do. Maybe also move a few parameters to match v5, unless the changes were intentional (@nohwnd ?). E.g. param (
[Parameter(ValueFromPipeline = $true, Mandatory = $true, Position = 5)]
[ScriptBlock]$ScriptBlock,
[Parameter(Position = 0)]
[String]$ExceptionMessage,
[Parameter(Position = 1)]
[String]$FullyQualifiedErrorId,
[Parameter(Position = 2)]
[Type]$ExceptionType,
[Parameter(Position = 3)]
[String]$Because,
[Switch]$AllowNonTerminatingError
) This will also be relevant for the future We avoided this issue in In general I'd recommend sticking with named parameters in these commands. Multiple positional parameters are hard to read for others. |
@johlju For the conversion be aware that |
For the conversion module I'm currently writing I can shift these around, so not an issue there at least. 😊 It is only an issue for my module when there is a new positional parameter put before or between those that exist in the Pester 5 syntax, like ScriptBlock.
For
Personally historically I have done a mix of positional and named parameters. I'm trying to support all scenarios I can think of in the conversion module (maybe not all edge cases). Also to be able to convert from positional to named parameters or vice versa (where positional is supported). In the end I'm hoping I can make a module that can be also be for example used ScriptAnalyzer to switch between named or positional depending on preference. Then we could have QA tests that make sure correct style is used (for example only named parameters). But that is a future project.
Good to know! I saw that in the syntax, but did not know it was the default now. |
@fflaten You are correct, |
Checklist
What is the issue?
When having a test like this in Pester 5 syntax, that is using positional parameters:
Trying to convert it to Pester 6 syntax:
Will fail with error:
This is due to that parameter
ScriptBlock
is expected to be the first positional parameter. As far as I can see this will be an issue when converting between Pester 5 to Pester 6 syntax and wanting to using pipeline input and using positional parameters.Expected Behavior
With Pester 6 syntax be able to have a scriptblock as pipeline input and also be able to only use positional parameters.
Steps To Reproduce
Run this:
Describe your environment
Possible Solution?
If the
ScriptBlock
positional parameter would be moved last that could solve this? Or, is using ScriptBlock as pipeline input something we should move away from with Pester 6 syntax?The text was updated successfully, but these errors were encountered: