Cmdlet under test with parameter $ExecutionContext causes Internal Error.

[alx9r]

I have encountered this error:

Internal error detected:  Mock for 'Write-Error' in module '' was called, but does not exist in the mock table.
      at line: 733 in C:\oltkPS\modules\Pester\Functions\Mock.ps1

There's a comment on line 732 that says

If this ever happens, it's a bug in Pester. The scriptBlock that calls Invoke-Mock should be
removed at the same time as the entry in the mock table.

Repro

Running the following test reproduces the error. If you change $ExecutionContext to anything else the error seems to be avoided. It looks like Mock.ps1 uses $ExecutionContext internally.

module.psm1

Function InternalErrorRepro
{
    [CmdletBinding()]
    param
    (
        $ExecutionContext
    )
    process
    {
        Write-Warning 'warning message'
    }
}

module.Tests.ps1

Import-Module module

InModuleScope module {
Describe 'InternalErrorRepro' {
    Mock -Verifiable Write-Warning
    Context 'context' {
        It 'does stuff' {
            InternalErrorRepro 
            Assert-MockCalled Write-Warning
        }
    }
}
}

Workaround

Obviously, avoiding cmdlet parameters named $ExecutionContext is a workaround. I wonder whether there is the potential for other naming collisions as well.

Solution

Ideally the cmdlet parameters and the internals of Mock.ps1 would not share the same namespace. If that's can't be achieved, perhaps $ExecutionContext (and whatever other variables that share namespace with the cmdlet parameters) could be suffixed with some random characters to reduce the likelihood of a collision.

[alx9r]

It looks like $ExecutionContext is an automatic variable, so there's an argument that name should be avoided in cmdlet parameters anyway.

[dlwyatt]

Yeah, generally a bad idea to step on automatic variables. I'll have a look at the code and see if I can think of a way to make it still work even if the test code is weird like that.

[alx9r]

@dlwyatt Thanks for checking this out. FWIW, my $ExecutionContext Cmdlet parameter got named as such naturally to mirror the property of an SCCM .NET API object ([Microsoft.ConfigurationManagement.ApplicationManagement.Installer]).

[dlwyatt]

No worries, I do the same thing often. :) $error and $host tend to get stepped on quite a bit, in particular (and trying to overwrite $error will actually cause an error, which is fun.)

[alx9r]

I just updated to 3.3.7 and ran this same repro. I'm getting this error now:

      Cannot bind argument to parameter 'SessionState' because it is null.
      at line: 712 in C:\PS\ext-modules\Pester\Functions\Mock.ps1

This is strange because It 'Should work even if the function is weird and steps on the automatic $ExecutionContext variable.' passes and looks like it does the same thing.

[dlwyatt]

Crap. I'm on it.

[dlwyatt]

K, will be fixed in 3.3.8, which I'll have released in a few minutes.

[alx9r]

That works. Thanks very much. :)

[dlwyatt]

I may wind up having to go back on this fix. $ExecutionContext is a pretty critical automatic variable, and avoiding its usage is now running us into other problems (if someone mocks a command that is used inside the mock bootstrap function, it results in infinite recursion.) We can avoid the infinite recursion by using methods in $ExecutionContext instead.

I'm still thinking on this, and maybe I can find a better solution, but if not, I think it's a lesser evil to say that people shouldn't overwrite the automatic variable.

[alx9r]

Using the names of automatic variables for parameter names tempts fate. My gut tells me that Pester ought to throw an exception when it is asked to mock a parameter named ExecutionContext. But doing that now would mean any tests that currently mock an ExecutionContext parameter will begin to fail. I'm not sure how acceptable that is. That change would be particularly painful for the unfortunate user who has mocked a function with an ExecutionContext parameter that they can't alter.