Issues calling a Mock when a Mandatory attribute is included on a parameter about pester HOT 3 CLOSED

Hi. Thanks for the detailed report with repros!

This isn't an Pester-issue, but expected PowerShell's behavior when using a cmdlet/advanced function which you enable by using [CmdletBinding()] or [Parameter()].

The simple solution is to remove your param-block in the mock scriptblock.
The param-block is not necessary as mocks are generated with all the original parameters and parameter-types.

When calling a mock, you actually invoke a Pester-generated wrapper which accepts the same [string[]]$Path parameter as Test-Path. After some internal logic, the parameter is passed to the scriptblock you provide, which tries to convert it to [string].

I'm not sure why the PowerShell codebase allows the [string[] -> [string] conversion for simple functions, but in general advanced functions/cmdlets are a lot more strict when it comes to parameter validations.

# Using [string[]] as input as that's what the Pester will pass to
# your mock's scriptblock unless you use `Mock -RemoveParameterType 'Path' ...` which changes it to `[object]`
$myValue = [string[]]('SomePath')

function test {
    param(
        [Parameter()]
        [string]$Path
    )

    if ($Path -eq 'SomePath') {
        return $true
    } else {
        return $false
    }
}

test -Path $myValue

# output
test: C:\Users\Frode\Desktop\Demo\demo.ps1:16:12
Line |
  16 |  test -Path $myValue
     |             ~~~~~~~~
     | Cannot process argument transformation on parameter 'Path'. Cannot convert value to type System.String.

Wrapping the Test-Path expression in curly braces corrected this for that case:

    It "Tests the top-level folder. Relative path." {
        { Test-Path 'SomeHostFolder' } | Should -Be $true
    }

However, a test which generated a $false response from the mock would now result in this output:

Expected $false, but got { Test-Path 'Invalid' }.

The first sample is a false positive and intended behavior. Should -Be uses the -eq operator like $ExpectedValue -eq $ActualValue. The provided scriptblock isn't executed but passed as-is as the -ActualValue parameter in Should. Because it's used on the right side of the operator, it will be cast to the type of your expected value, $true (bool), on the left side. A scriptblock is not null, which usually becomes $true when cast to [bool].

> $true -eq { 'hello' }
True

from pester.

Thanks so much for your detailed response, @fflaten! This is my first time using PowerShell and Pester, so I hope you'll forgive my lack of knowledge.

Thanks also for the explanation of the string[] -> string coercion and the scriptblock evaluation to $true. I'm sure that will be useful on future projects...if I ever get this one finished :)

from pester.

You're very welcome. I'm sure this issue will be useful for others in the future as well, so time well spent.

Good luck with your project 🙂

from pester.