Mocking replaces a PowerShell command called by code under test with controlled behavior. A mock intercepts the call and returns predetermined output or throws a chosen error, so a unit test evaluates a function’s logic rather than the state of the local machine, network, or external service. section 13.2 section 13.2.3
Use mocks when a dependency makes tests variable, difficult to arrange, or unsafe to call directly. A hotfix check can receive a simulated installed result, a specific “not found” error, or an unrelated failure without requiring particular patches or unreachable computers. This makes the same tests behave consistently wherever they run. section 13.2.2 section 13.2.3
Build a focused Pester mock by following this workflow:
- Load the function under test in BeforeAll, then group related cases with Describe and Context. section 13.1 section 13.2.3
- Declare Mock with the dependency name and a script block that returns the required result or throws the required error. section 13.2.3
- Place each mock at the narrowest useful scope; a mock in BeforeAll or Describe applies to descendant tests, while separate Context blocks isolate different behaviors. section 13.2.3
- Add a parameter filter when one command is called in multiple ways, so only the intended invocation is replaced. section 13.3.3
- Assert the function’s output and, where needed, assert that the mock was invoked with the expected parameters. section 13.3.4 section 14.1.3
Hotfix status without machine-specific setup
A Get-HotFixStatus function treats a successful Get-HotFix call as “found,” a particular missing-hotfix error as “not found,” and other errors as terminating failures. Separate Context blocks mock Get-HotFix for each case, then assert true, false, or a thrown error. The test checks the function’s decision logic without depending on installed patches. section 13.2 section 13.2.3
For complex dependency output, capture representative data into files and have mocks reload it. HTML saved from catalog searches can drive ConvertFrom-Html and Invoke-WebRequest mocks; CLIXML preserves PowerShell object type information when recreating Get-CimInstance results. Parameter filters distinguish calls such as URI input from piped content. section 13.3.3 section 14.1.1
Mocks suit unit tests because the target is internal logic. Integration tests should exercise components together and use broader assertions against live dependencies; do not mock custom code when verifying that the full system works together. section 13.3.4 section 13.6
Mock ConvertFrom-Html -ParameterFilter{ $URI } -MockWith {
$Path = Join-Path $PSScriptRoot "$($URI.AbsoluteUri.Split('=')[-1]).html"
ConvertFrom-Html -Path $Path
}
Mock Invoke-WebRequest -MockWith {
$Path = Join-Path $PSScriptRoot "$($URI.AbsoluteUri.Split('=')[-1]).html"
$Content = Get-Content -Path $Path -Raw
[pscustomobject]@{
Content = $Content
}
}
This listing shows parameter-filtered mocks that replay saved HTML for distinct ConvertFrom-Html and Invoke-WebRequest calls. section 13.3.3
