Is there any reason why using [Parameter()] on It block parameters in parameterised tests, breaks the tests?

[plastikfan]

Taking the test suite as documented in the Pester readme:

Describe 'Pester readme tests' -Tag 'Current' {
  BeforeAll {
    # your function
    function Get-Planet ([string]$Name = '*') {
      $planets = @(
        @{ Name = 'Mercury' }
        @{ Name = 'Venus' }
        @{ Name = 'Earth' }
        @{ Name = 'Mars' }
        @{ Name = 'Jupiter' }
        @{ Name = 'Saturn' }
        @{ Name = 'Uranus' }
        @{ Name = 'Neptune' }
      ) | foreach { [PSCustomObject]$_ }

      $planets | where { $_.Name -like $Name }
    }
  }

  # Pester tests
  Describe 'Get-Planet' {
    It "Given no parameters, it lists all 8 planets" {
      $allPlanets = Get-Planet
      $allPlanets.Count | Should -Be 8
    }

    Context "Filtering by Name" {
      It "Given valid -Name '<Filter>', it returns '<Expected>'" -TestCases @(
        @{ Filter = 'Earth'; Expected = 'Earth' }
        @{ Filter = 'ne*'  ; Expected = 'Neptune' }
        @{ Filter = 'ur*'  ; Expected = 'Uranus' }
        @{ Filter = 'm*'   ; Expected = 'Mercury', 'Mars' }
      ) {
        param (
          [Parameter()]
          $Filter,

          [Parameter()]
          $Expected
        )

        $planets = Get-Planet -Name $Filter
        $planets.Name | Should -Be $Expected
      }

      It "Given invalid parameter -Name 'Alpha Centauri', it returns `$null" {
        $planets = Get-Planet -Name 'Alpha Centauri'
        $planets | Should -Be $null
      }
    }
  }
}

In this example above, all I have done is to use the [Parameter()] attribute on the parameters passed into the It block, but for some strange reason, it breaks the tests with these parameter binding errors:

[-] Pester README tests.Get-Planet.Filtering by Name.Given valid -Name 'Earth', it returns 'Earth' 3ms (3ms|1ms)
 ParameterBindingException: A parameter cannot be found that matches parameter name '_'.

[-] Pester README tests.Get-Planet.Filtering by Name.Given valid -Name 'ne*', it returns 'Neptune' 2ms (1ms|1ms)
 ParameterBindingException: A parameter cannot be found that matches parameter name '_'.

[-] Pester README tests.Get-Planet.Filtering by Name.Given valid -Name 'ur*', it returns 'Uranus' 1ms (1ms|1ms)
 ParameterBindingException: A parameter cannot be found that matches parameter name '_'.

[-] Pester README tests.Get-Planet.Filtering by Name.Given valid -Name 'm*', it returns 'Mercury Mars' 2ms (1ms|1ms)
 ParameterBindingException: A parameter cannot be found that matches parameter name '_'.

I discovered this whilst writing some of my own parameterised tests that were in-explicably failing and decided to reproduce this error on other code, to rule out anything I may have been doing wrong accidentally.

[fflaten]

It's because the use of ParameterAttribute will make the scriptblock advanced (like [CmdLetBinding()]) which doesn't allow arguments by default. So it fails to bind some of the hard-coded values Pester passes to the It-scriptblock, in this case the object for the current testcase.

I'm not really sure why the param-block is in the README-example tbh. You don't really need it for normal usage. All the testcase parameters are made available both as named variables and the current testcase-object/dictionary itself can be accessed through $_.

Any reason you need the ParameterAttributes? If not I'd remove them or maybe even the whole param-block.

[fflaten]

PS: you do need the param block when running InModuleScope (not illustrated here, but in my test suite I am using InModuleScope), otherwise the testcase parameters (like <Filter> and <Expected> in this case) would not be bound inside the It block.

This is fixed in 5.3 (#1957). If you got time, please try the beta to see if it works as expected.

[plastikfan]

Argh ok. I've just realised I haven't updated my version of pester for a while, I'm still running 5.1.1, but just to give you a hint as to what InModuleScope code I'm running:

Describe 'convert-ActionResult' {
  BeforeAll {
    Get-Module ims | Remove-Module -Force;
    Import-Module .\ims.psm1 `
      -ErrorAction 'stop' -DisableNameChecking -Force;
  }

  Context 'given: <Scenario> <Result>' {
    It 'should: return result with Success = <ExpectedSuccess>' -TestCases @(
      # string results
      #
      @{
        Scenario        = 'Positive string result';
        Result          = 'affirmative';
        ExpectedSuccess = $true;
      }

      , @{
        Scenario        = 'Negative empty string result';
        Result          = [string]::Empty;
        ExpectedSuccess = $false;
      }

    ) {
      InModuleScope ims -Parameters @{ Scenario = $Scenario; Result = $Result; ExpectedSuccess = $ExpectedSuccess; } {
        param(
          [string]$Scenario,
          [object]$Result,
          [boolean]$ExpectedSuccess
        )

        [PSCustomObject]$actionResult = convert-ActionResult -Result $Result;
        $($null -ne ${actionResult}.Success) | Should -BeTrue -Because $Scenario;
        $actionResult.Success | Should -Be $ExpectedSuccess;

        $($null -ne ${actionResult}.Payload) -xor $(
          $null -ne ${actionResult}.FailedReason
        ) | Should -BeTrue -Because $Scenario;
      }
    }
  }
}

The command under test is convert-ActionResult, which is internal to the module I've called ims.

If I remove the parameter passing in the InModuleScope statement, then the template parameters <Scenario>, <Result> and <ExpectedSuccess> are all unbound. I used this technique as a result of reading some module/data-driven test documentation on pester.dev, quite some time ago and it served me well ever since.

I'm going to update my version of pester and retest.

[plastikfan]

I've just updated to version 5.3.0-beta, and tested and so far, there's no difference in behaviour. I'll continue this discussion on #1957.

[fflaten]

If I remove the parameter passing in the InModuleScope statement, then the template parameters <Scenario>, <Result> and <ExpectedSuccess> are all unbound.

5.3 removes the requirement for the param-block inside the scriptblock. You still need to specify InModuleScope MyModule -Parameters ....

That's because we're passing data to another state (inside the module), so we need to be specific to not pollute the module.

[plastikfan]

✨ BINGO!!!! 😃