Forem: Mark Wragg

Two ways to use Pester to Mock objects with strongly typed parameters

Mark Wragg — Thu, 24 Oct 2024 17:43:16 +0000

When writing Pester unit tests, it's pretty common to want to Mock cmdlets so that you can validate they've been called when expected, and the expected number of times.

BeforeAll {
  Mock "Some-Command" -MockWith {}
}

It "Should invoke Some-Command the expected number of times" {
  Should -Invoke "Some-Command" -Times 1 -Exactly
}

Some commands however can be difficult to Mock because one of more of their input parameters requires a specific type of object. An example of this is the Azure storage cmdlet New-AzStorageContext. This creates a Microsoft.WindowsAzure.Commands.Storage.AzureStorageContext type object, which other storage cmdlets then expect as an input.

There's two ways to handle this:

1. Use New-MockObject

The New-MockObject Pester cmdlet allows you to create an object of a specified type, with the properties and methods that you require. For New-AzStorageContext you could do something like this:

Mock New-AzStorageContext -MockWith {
  New-MockObject -Type Microsoft.WindowsAzure.Commands.Storage.AzureStorageContext -Properties @{
    StorageAccountName = 'somestorageaccount'
    Context            = @{
    StorageAccountName = 'somestorageaccount'
    }
  }
}

However for New-MockObject to work, the type you want to fake has to be available on the system (i.e the relevant module/cmdlets must be installed).

2. Use -RemoveParameterType

The alternative option is to use the -RemoveParameterType parameter on the Mock that needs to receive the strongly typed object. This removes the strong typing on the specified input parameter and means that you can therefore Mock the source object's output as just a [pscustomobject]. For example:

Mock New-AzStorageContext -MockWith {
  [pscustomobject]@{
    StorageAccountName = 'somestorageaccount'
    Context            = @{
    StorageAccountName = 'somestorageaccount'
    }
  }
}

And then on the receiving Mock you do:

Mock Get-AzStorageTable -RemoveParameterType 'Context' -MockWith {
  [pscustomobject]@{
    Name       = 'sometable'
    CloudTable = @{ Name = 'somename' }
  }
}

This also negates the need for the type to be available on the system where your tests execute.

For more on Mocking with Pester see here.

How to remove null or empty string values from a list in Terraform

Mark Wragg — Tue, 22 Oct 2024 10:36:31 +0000

I was recently implementing a change to a Terraform azurerm_key_vault Key Vault resource to allow a specified list of IP addresses on the firewall. The IP addresses would be provided via an Azure DevOps variable, which would contain a comma-separated list. This list is then turned into a list value in Terraform via the split function.

I wanted the change to the resource to continue to work if the variable was not specified, but when no value was provided the result would be an empty string, and this was not a valid value for the ip_rules property of the Key Vault resource, which requires either null or a list of values.

The solution was to use the compact function. This takes a list of strings and removes any null or empty string elements:

resource "azurerm_key_vault" "keyvault" {
  name                = var.keyVaultName
  location            = var.location
  resource_group_name = var.rgName
  sku_name            = "standard"
  tenant_id           = data.azurerm_client_config.current.tenant_id

  network_acls {
    default_action = "Deny"
    ip_rules       = compact(split(",", var.keyVaultAllowedIPs))
  }
}

The compact function appears to have been a part of Terraform since at least version 1.1 but looking at the documentation it appears that it only started to remove null values from strings (as well as empty strings) as of version 1.5.

At time of writing the current production release of Terraform is 1.9.

Redirect Out-File to TestDrive: in your PowerShell Pester test scripts with this one weird trick

Mark Wragg — Sat, 19 Oct 2024 14:01:19 +0000

I was writing some Pester unit tests recently for a PowerShell script that creates a modified version of a template file before it is then uploaded via an API and deleted. The script uses Out-File to output the updated file and because it only exists temporarily the location it writes to is hard coded in the script.

I wanted to write some tests that would validate the file was created and with the expected updated values. I could have just let the script write the file to it's default location and validate it there, but I'd have to mock Remove-Item to stop it deleting the file and then have my test script remove it afterwards. Another approach might have been to do some refactoring, have the output file and input parameter of the script, or break the script up into smaller functions, but I didn't particularly want to change the script.

Pester provides an automatic location TestDrive: that can be used to isolate file operations somewhere unique and that it automatically cleans up when the test completes, so all I needed to do was override the behaviour of Out-File to write to TestDrive:. You can do that with a Mock, and the one-weird-trick here is to store the Out-File command into a variable so that we can use it within the Mock, but change it's input parameters:

BeforeAll {
  $OutFile = Get-Command -Name 'Out-File'

  Mock Out-File -ParameterFilter { $FilePath -match 'file.txt' } -MockWith {
    $InputObject = $PesterBoundParameters['InputObject']
    $FilePath = Join-Path $TestDrive 'file.txt'
    & $OutFile -InputObject $InputObject -FilePath $FilePath
  }
}

It 'Should update the file with the expected values' {

  $FilePath = (Join-Path $TestDrive 'file.txt')

  $FilePath | Should -FileContentMatch 'expectedstring1'
  $FilePath | Should -FileContentMatch 'expectedstring2'
  $FilePath | Should -FileContentMatch 'expectedstring3'
}

It is necessary to put the command into a variable because once a command is mocked in a test script, calling it would invoke the Mock rather than the command, so you'd end up in a recursive loop. Note how the Mock uses $PesterBoundParameters to access the parameters that were passed to the command in the script, but we then override what would have been provided for -FilePath with our TestDrive: pathed value.

My script still mocked Remove-Item btw, so we could check that it had been called the expected number of times. There was no need to let it actually do a file removal because the clean up of TestDrive: takes care of that for us. It's usually best to mock away the destructive behaviour of cmdlets when testing so that if the script has been badly modified in some way you don't risk invoking the actual behaviour for the purpose of running your tests.

Hi, I'm Mark Wragg

Mark Wragg — Fri, 05 May 2017 14:30:21 +0000

👋 Hi! I am an Azure DevOps Engineer from the UK. I live in Basingstoke with my wife and three small humans.

I've worked full-time in IT since graduating with a Degree in Computing in 2003, with the exception of a year out to give Teacher Training a whirl. Much of my initial IT career experience was working in front-line operations roles, supporting infrastructure and SaaS applications hosted in private data centres and the cloud. Since 2017 I've worked as a DevOps Engineer and for the last few years as a contractor. My experience is predominantly with Microsoft technologies but I can generally turn a quick hand to any tool and I have experience with AWS and Azure as well as a variety of DevOps toolsets.

You can follow me on Twitter @markwragg.

I am particularly passionate about PowerShell and have spoken twice at PSDay.UK, the UK's annual PowerShell Conference. If you'd like to view my talks they can be found here:

Public Speaking

Measure all the things with Influx, Grafana and PowerShell -- PSDay Birmingham 2019
Mastering PowerShell Testing with Pester -- PSDay London 2018
How to Develop Cross-Platform Compatible Modules using PowerShell Code -- Southampton PowerShell Usergroup 2018 (slides only, not recorded)

Books

I also made voluntary contributions to the following books, which raised funds for the DevOps Collective OnRamp scholarship:

The PowerShell Conference Book volume 1 -- contributed a chapter on PowerShell code testing with Pester
The PowerShell Conference Book volume 2 -- contributed a chapter on monitoring with Influx, Grafana and PowerShell

Open Source

I maintain a number of Open Source code repositories for tools that I've developed that I felt could be useful to the wider community. You can find those in my profile on GitHub. Some that are particularly popular include:

PowerShell-Influx -- a PowerShell module for sending metrics into the time-series platform Influx.
Test-ActiveDirectory -- a set of Pester tests for validating the health of a deployment of Active Directory.
PowerShell-SlackBot -- a PowerShell module for hosting a chat bot for Slack using PowerShell and TCP Sockets. The chat bot can then be configured to listen to and respond to specific messages and run PowerShell commands that are initiated from within a chat window.

If you have any other burning questions about me, feel free to get in touch! :)