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)