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.
Top comments (0)