Recently, I have been writing/ reading a lot of Pester tests (both Unit and Integration) for infrastructure validation.
One of the classic limitation hit during mocking with Pester is that you can have different mocks based on different arguments to a parameter (e.g using parameterFilter with Mock ) but not based on a counter.
For Example - See below, I have two mocks for Get-Process cmdlet based on the name passed to it.
This is really helpful, but there is a case where we want different mocks to occur based on a an incremental counter (number of times) a function/Cmdlet etc. are called in our script.
Avery basic function (bad example) illustrating the point where this might be needed is below :
Note that the above function calls Get-Service twice (line 3 & line 9).
Now with this very crude counter based mocking, my unit tests pass.
Well it is really up to your creativity on how you want to push the code coverage ;)
One of the classic limitation hit during mocking with Pester is that you can have different mocks based on different arguments to a parameter (e.g using parameterFilter with Mock ) but not based on a counter.
For Example - See below, I have two mocks for Get-Process cmdlet based on the name passed to it.
Mock -CommandName Get-Service -ParameterFilter {$Name -eq 'winrm'} -mockwith {[PSCustomObjet]@{Status='Running'}}
Mock -CommandName Get-Service -ParameterFilter {$Name -eq 'bits'} -mockwith {[PSCustomObjet]@{Status='Stopped'} |
This is really helpful, but there is a case where we want different mocks to occur based on a an incremental counter (number of times) a function/Cmdlet etc. are called in our script.
A
001
002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 |
function EnsureServiceStarted {
param($Name) $Service = Get-Service -name $name if ($Service.Status -eq 'Running') { return $true } else { Start-Service -name $name # check if the service is started $Service = Get-Service -Name $name if($Service.Status -eq 'Running'){ return $true } else { return $false } } } |
Note that the above function calls Get-Service twice (line 3 & line 9).
- Line 3, the code fetches the current service controller object using Get-Service and then checks if the status is equal to 'Running'. If it is then returns true else it tries to start it.
- Line 9 , after trying to start the service, Get-Service cmdlet is used again to fetch the updated status property on it.
All simple and easy right!
But how do you mock Get-Service with pester for testing the logic of starting a stopped service.
It seems you can get a bit crafty, with Pester & PowerShell and do a counter based mocking.
You create a script scope counter and while mocking put the logic in scriptblock passed to the -MockWith parameter.
It seems you can get a bit crafty, with Pester & PowerShell and do a counter based mocking.
You create a script scope counter and while mocking put the logic in scriptblock passed to the -MockWith parameter.
001
002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 |
Describe 'EnsureServiceStarted' -Tags Counter { Context 'Starting a Stopped service' { # Arrange $Script:counterGetService = 1 Mock -CommandName Get-Service -MockWith { if ($Script:counterGetService -eq 1){ # counter eq 1 $Script:counterGetService++ @{Status = 'Stopped'} } else { @{Status = 'Running'} } } Mock -CommandName Start-Service -MockWith {} # Act EnsureServiceStarted -Name WinRM # Assert It 'Should call the Get-Service twice' { # Get-Service called twice within the function $Script:counterGetService | Should be 2 Assert-MockCalled -CommandName Get-Service -Times 2 -Exactly -Scope Context } It 'Should call Start-Service once' { Assert-MockCalled -CommandName Start-Service -Times 1 -Exactly -Scope Context } } } |
Now with this very crude counter based mocking, my unit tests pass.
Well it is really up to your creativity on how you want to push the code coverage ;)