- Create a certificate-signed RDP shortcut via Group Policy - Fri, Aug 9 2019
- Monitor web server uptime with a PowerShell script - Tue, Aug 6 2019
- How to build a PowerShell inventory script for Windows Servers - Fri, Aug 2 2019
A task that software developers have become used to over many decades but one that recently come to light for PowerShell scripters is testing. Software developers have been building large applications for decades now. These applications had to be improved and maintained. The only way to ensure the application did not break when making changes was by developing and running tests against various pieces to ensure everything still worked.
People writing scripts (not software) never really needed to spend the time to write tests. Writing good tests nearly doubled development time and this is just a script, right? It's not like it's enterprise-worthy code. Nowadays, however, things are changing in the DevOps world. PowerShell has taken off not only as a simple scripting language but as a DevOps tool that businesses heavily rely on to deploy and manage production infrastructure. Things are getting serious for PowerShell "scripters", and some are turning into PowerShell "developers".
As a result of this shift, we now have Pester, a PowerShell testing framework. Among other things, Pester has a concept in common with many other testing frameworks called assertions. In simplest terms, assertions are a way to "assert" if your code is doing what you think it is. Assertion functions allow you to validate various routines in your code to result in a pass/fail scenario.
Pester implements assertions via the should command. The should command, according to the Pester wiki, is:
…a command that provides assertion convenience methods for comparing objects and throwing test failures when test expectations fail.
The should command allows you to pass the result of code and compare it against what you expect that result to be. The should command has various operators to test for different kinds of conditions. The simplest one is the be operator. This is an operator that checks for equality. For example, if you expect a $var variable to be equal to 'myvar,' in straight PowerShell you might do something like this:
If ($var –eq 'myvar') {
## it's equal to myvar
} else {
## it's not equal to myvar
}
In Pester, using the should command with the be operator significantly reduces the code length. The same functional check can be accomplished with Pester in a single line.
$var | should be 'myvar'
The should command will always be used in a Pester it block which is contained inside of a describe block. To demonstrate this, I'll create a file called MyTests.Tests.ps1 inside of a folder called PesterTests. I've called my test file this because when Pester is invoked, it will always check for files that end in Tests.ps1.
Inside of the MyTests.Tests.ps1 script is my simple test that looks like this:
describe MyTest {
it 'verifies something' {
$var = 123
$var | should be 123
}
}
I'll execute this test by running Invoke-Pester and pointing at my C:\PesterTests folder. Pester will automatically find each file ending in Tests.ps1 and will execute it.
Executing Pester
You can see that my test in the it block passed. It passed because $var was equal to the 123 integer. This was a simple example. Let's say I want to get more specific and check for the type of variable. To do this, I can use the beoftype operator. I'll get more specific and cast my $var variable to an integer for demonstration purposes. Since I can add as many conditions as I'd like, I'll just use another should command in this same it block.
it 'verifies something' {
[int]$var = 123
$var | should be 123
$var | should beoftype int
}
If I run this again, I will again see success. However, if I change the type to a string, you can see that my test fails.
it 'verifies something' {
[string]$var = 123
$var | should be 123
$var | should beoftype int
}
Pester Test Failure
The should command has many other operators I can use as well. Let's say I want this variable to be case-sensitive. I'll change the variable to be alpha characters and change up the case a little bit.
it 'verifies something' {
[string]$var = 'aBc'
$var | should beexactly 'abc'
$var | should beoftype string
}
You'll see now that it fails because it's checking case.
Case Sensitivity in Pester
Finally, to highlight the fact that the should command isn't relegated to merely simple variables, I want to demonstrate that it can also catch exceptions.
Let's say I want to ensure my code doesn't throw a terminating error (exception). I can test for this by using the throw operator. To test this, I'll need to enclose my code in a scriptblock with brackets and use the throw operator.
it 'verifies something' {
{ throw 'some error occurred' } | should throw
}
This example will ensure my test passes.
As you can see, Pester assertions can be compelling. Since you can add as many references to should as necessary, you can check a nearly unlimited number of situations. Even if Pester does not include a should operator you need, since this is just PowerShell, you can slightly modify the code to return a result that a should operator can understand.
Let's say you have an array and you'd like to ensure it has the appropriate number of elements. There is no count operator. However, you can get the count property yourself and pass it to the be operator to check the count.
Subscribe to 4sysops newsletter!
it 'verifies something' {
@(1,2,3).Count | should be 3
}
Now that you've learned a little about Pester and how to use assertions, get to testing those scripts! For a full breakdown on what's possible with the PowerShell testing framework Pester check out The Pester Book by myself and Don Jones.
