Skip to content
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 - Needs more flexibility/power #279

Closed
ghostsquad opened this issue Feb 12, 2015 · 10 comments
Closed

Should Throw - Needs more flexibility/power #279

ghostsquad opened this issue Feb 12, 2015 · 10 comments

Comments

@ghostsquad
Copy link
Contributor

Asserting on the expected message in the exception is nice:

{ throw 'foo' } | Should Throw 'foo'

But what if I wanted to examine additional properties of the exception, or even the exception type? I'm forced to do this:

$caughtException = $null
try {
    throw (new-object system.notimplementedexception)
} catch {
    $caughtException = $_
}

$caughtException | Should Not Be $null
$caughtException.Exception.GetType() | Should Be ([System.NotImplementedException])
$caughtException.Exception.Message | Should ...
$caughtException.Exception.CustomProperty | Should ...

Proposed Syntax

$action = { throw (new-object system.notimplementedexception) }
$actualException = $action | Should Throw ([System.NotImplementedException]) "My Message" -PassThru
$actualException.CustomProperty | Should ...
@vors
Copy link
Member

vors commented Feb 12, 2015

👍

@dlwyatt
Copy link
Member

dlwyatt commented Feb 12, 2015

The way the Should command is currently written is pretty limited. This sort of expansion would be easier if we were to rewrite Should to use dynamic parameter sets instead of its current parse and command lookup approach. In terms of usage, this would just involve adding a hyphen to the operators:

$action | Should Not Throw becomes $action | Should -Not -Throw

Unfortunately, that would break every single Pester script that exists today, but if I were writing the module from scratch, that's probably how I'd do it.

@ghostsquad
Copy link
Contributor Author

To support backwords compatibility, you can map one style of Should to the other. Maybe writing a warning that the old detected version of using Should has been deprecated.

#New
Function Should {
    [cmdletbinding(DefaultParameterSetName="Old")]
    param (
        [Parameter(ParameterSetName="New")]
        [Type]$Type,

        [Parameter(ParameterSetName="New")]
        [String]$Msg,

        [Parameter(ParameterSetName="New")]
        [Switch]$Throw,

        [Parameter(Position=0, ParameterSetName="Old")]
        [object]$Old1,

        [Parameter(Position=1, ParameterSetName="Old")]
        [object]$Old2,

        [Parameter(Position=2, ParameterSetName="Old")]
        [object]$Old3,

        [Parameter(Position=3, ParameterSetName="Old")]
        [object]$Old4
    )

    Write-Host ("ParameterSet: {0}" -f $PSCmdlet.ParameterSetName)
    Write-Host "Throw: $Throw"
    Write-Host "Type: $Type"
    Write-Host "Msg: $Msg"
    Write-Host "Old1: $Old1"
    Write-Host "Old2: $Old2"
    Write-Host "Old3: $Old3"
    Write-Host "Old4: $Old4"
}

New Syntax Test

$ Should -Throw -Type ([NotImplementedException]) -Msg 'MyMsg'
ParameterSet: New
Throw: True
Type: System.NotImplementedException
Msg: MyMsg
Old1:
Old2:
Old3:
Old4:

While supporting backwords compatibility, named parameters are required to support the new features.

Old Syntax Test

$ Should Throw 'MyMsg'
ParameterSet: Old
Throw: False
Type:
Msg:
Old1: Throw
Old2: MyMsg
Old3:

@dlwyatt
Copy link
Member

dlwyatt commented Feb 12, 2015

That could work.

@dfch
Copy link

dfch commented Apr 27, 2015

👍 for a more flexible should throw syntax (especially catching specific exceptions)

@dlwyatt dlwyatt self-assigned this Apr 27, 2015
@dlwyatt
Copy link
Member

dlwyatt commented Apr 27, 2015

I'm going to make this my first priority after we get a few other things merged.

@jlucktay
Copy link

jlucktay commented Dec 4, 2016

I'd also like to be able to specify exception types with the Should Throw assertion. 👍

@dfch
Copy link

dfch commented Dec 9, 2016

fyi as this issue does not seem to move very much

I created a PoSH module with Pester extensions that address some of the mentioned issues:

In short, with it you can do something like this:

  • { 1 / 0 } | Should ThrowException DivideByZeroException
  • { Invoke-InexistentCmdlet } | Should ThrowCategory 'NotFound;
  • { 1 / 0 } | Should ThrowException '\w+\.DivideByZeroException$'; (with regex parsing)

See:

@it-praktyk
Copy link
Contributor

@dfch, can you add information about your module to the newly created wiki article Articles and other resources.

@nohwnd, is it addressed in your Assert project? If yes I don't think so that issue still should be opened.

@nohwnd, please add the Assert project to the list too. Thank you.

@nohwnd
Copy link
Member

nohwnd commented Nov 12, 2017

@it-praktyk Yes it does. I should finish it and propose merging it.

@nohwnd nohwnd assigned nohwnd and unassigned dlwyatt Dec 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants