- Validating your Infrastructure as Code.
- Tests if the infrastructure components are functional.
+++
Fits into the DevOps ecosystem. | Is my infrastructure functioning as expected?
- Can be used.
- Maintenance nightmare.
+++
Tip - Avoid writing scripts for validating your infrastructure.
Pester is a Unit testing framework. Only the code logic is tested.
Function Get-ServerInfo {
Get-CIMInstance -Class Win32_ComputerSystem |
Select-Object -Property *
}
Describe 'Get-ServerInfo Unit tests' {
# Arrange
Mock -Command Get-CimInstance -FilterParameter {$Class -eq 'Win32_ComputerSystem' }
# Act
Get-ServerInfo
# Assert
It "Should query the Win32_ComputerSystem class" {
Assert-MockCalled -Command Get-CimInstance -Times 1 -Exactly -Scope Describe
}
}
+++
But Pester can be extended to validate/test Infrastructure as well.
Describe "TestIPConfiguration" {
It "Should have a valid IP address on the Management NIC" {
(Get-NetIPAddress -AddressFamily IPv4 -InterfaceAlias 'vEthernet(Management)' | Select-Object -ExpandProperty IPAddress) |
Should be '10.10.10.1'
}
}
+++
PoshSpec adds yet another layer of abstraction on our infrastructure tests. The tests look concise and easy to maintain.
Describe "TestIPConfiguration" {
Context "Validate the Management NIC " {
# Custom public type added to PoshSpec for our use.
IPv4Address 'vEthernet(Management)' {Should be '10.10.10.1'}
}
}
- Targeting remote nodes for ops validation is still an overhead.
- Remote nodes need to bootstrapped before invoking the ops validation.
- Challenge in specifying node and solution configuration data.
Targeting tests written to remote node(s). PSRemotely was engineered with solution stack operations validation in mind. Few of its features:-
- Target Pester/PoshSpec based operations validation tests on the remote nodes.
- Decouples node and solution configuration data using DSC config data syntax.
- Self-contained framework, bootstraps remote node(s) for running the ops validation.
- Allows re-running failed tests.
- Easier debugging.