{"id":15170,"date":"2020-12-03T13:45:36","date_gmt":"2020-12-03T12:45:36","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/an-introduction-to-pester-unit-testing-and-infrastructure-checks-in-powershell\/"},"modified":"2025-10-01T11:48:49","modified_gmt":"2025-10-01T09:48:49","slug":"an-introduction-to-pester-unit-testing-and-infrastructure-checks-in-powershell","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/an-introduction-to-pester-unit-testing-and-infrastructure-checks-in-powershell\/","title":{"rendered":"An Introduction to Pester – Unit Testing and Infrastructure checks in PowerShell"},"content":{"rendered":"

Introduction<\/h3>\n

If you never heard of it, Pester<\/a> is a PowerShell module, written in PowerShell.
\nIt’s a framework for writing and running unit tests<\/a>, integration tests, and also infrastructure checks as we will see in a moment.
\nPester is used for example to test PowerShell Core<\/a> and Pester itself.<\/p>\n

In this blog post, I’ll do a short introduction to Pester with Installation and basic checks examples.<\/p>\n

Installation<\/h3>\n

Pester is shipped by default with Windows 10 and Windows Server 2016. The version installed is 3.4.
\nThe latest version is available in the PSGallery. It is currently version 5.1.
\nIf you have the 3.4 version installed and would like to update it you will face errors with Update-Module. You need to use the following command to get the latest version:<\/p>\n

PS C:\\> Install-Module -Name Pester -Force -SkipPublisherCheck\nPS C:\\> Get-InstalledModule\n\nVersion    Name                                Repository           Description\n-------    ----                                ----------           -----------\n5.1.0      Pester                              PSGallery            Pester provides a framework for...\n<\/pre>\n
PowerShell function example<\/h3>\n
I will now show you a very basic Pester test.
\nLet’s say I want to write a Pester test for the following PowerShell function.\"\"<\/a><\/p>\n
This is a very basic function that reverses the string characters. This is the output:\"\"<\/a><\/p>\n
Now that I have a working function I can start to write the Pester test.<\/div>\n
Create a Pester Tests file<\/h3>\n
The Pester function New-Fixture will create a template file for me but you could definitely create it yourself.
\nBy convention, Pester test files should end with “Tests.ps1”.<\/div>\n
\"\"<\/div>\n
The Tests file has been created.<\/div>\n
\"\"I already edited the file and wrote the test.
\nThis is what a Pester test looks like:\"\"<\/a><\/div>\n
<\/div>\n
Pester basics<\/h3>\n
Pester is very declarative and easy to read.
\nYou can ignore the first 3 rows in the Tests file, they came from the New-Fixture function and just dot sources the function to test into the PowerShell session.<\/p>\n
The main commands with Pester are Describe, It, Context, and Should.<\/p>\n
Describe<\/a> is a block that contains tests. You will often have one Describe block for each function you want to test.
\nContext<\/a> blocks are like Describe, they contain It blocks. They are optional and are useful to organize your test code.
\nThe It<\/a> block is the one that actually contains the test. The It block should have an expressive phrase describing the expected test outcome.
\nFinally, the Should<\/a> command defines the test condition to be met. If the assertion is not met the test fails and an exception is thrown up. I used the -Be parameter. Many more are available like -BeFalse, -BeGreaterOrEqual, -BeLike, -Contain, etc.<\/p>\n
In this example the test is simple. I set the expected value that I should get and I compare it to the actual value returned by the function.<\/p>\n
Running Pester Tests<\/h3>\n
Now let’s run the test itself with Invoke-Pester.<\/div>\n
\"\"<\/a><\/div>\n
<\/div>\n
Also, running Invoke-Pester without any parameter will run all the “Tests.ps1” files in the current location.<\/div>\n
\"\"<\/a><\/div>\n
<\/div>\n
So, everything is green. We can see that one test was performed and it Passed.<\/div>\n
<\/div>\n
Now let’s say another developer worked on the Get-ReverseString function and the latest change introduced a bug. \"\"<\/a>Function behavior has changed and the Pester test will now throw a beautiful exception:\"\"<\/a><\/div>\n
What is great is all the details (in red color) we can get when a test fails.<\/div>\n
Infrastructure Testing<\/h3>\n
Pester is often used by sysadmin to do infrastructure testing. Your environment changes frequently and you need to be sure that your infrastructure is aligned with your standard.
\nHere are a few examples of such tests. The test is done directly inside a Pester code block not using a function like I did previously.<\/p>\n
Check that my Windows Server Power Plan is set to High Performance.<\/p>\n
Describe \"Power Plan\" {\n    $PowerPlan = (Get-CimInstance -ClassName Win32_PowerPlan -Namespace 'root\\cimv2\\power' | Where-Object IsActive).ElementName\n    It \"Should be set to High Performance\" {\n        $PowerPlan | Should -be \"High Performance\" -Because \"This Power Plan increases performance\"\n    }\n}<\/pre>\n
The best practice for SQL Server disks is to have an allocation unit size of 64 KB, here is the check:<\/p>\n
Describe \"File Allocation Unit Size\" {    \n    $BlockSize = (Get-CimInstance -ClassName Win32_Volume | Where-Object DriveLetter -eq $SQLDisk).BlockSize\n    It \"Should be 64 KB\" {\n        $BlockSize | Should -Be 65536 -Because \"It is recommended to set a File Allocation Unit Size value to 64 KB on partitions where resides SQL Server data or log files\"\n    }\n}<\/pre>\n
Here I used the dbatools<\/a> command Get-DbaErrorLogConfig to get the number of files configured for my ErrorLog. My best practice is to have 30 files instead of 6 by default.<\/p>\n
Describe \"SQL Server Error Log Files\" {\n    $errorLogCount = (Get-DbaErrorLogConfig -SqlInstance $SQLInstance).LogCount\n    It \"Should have Number of Log files set to 30\" {\n        $errorLogCount | Should -Be 30 -Because \"Best practices requires 30 logs files to perform daily recycling\"\n    }\n}<\/pre>\n
When all put together the output of the Tests looks like this:
\n\"\"<\/a>As you can see I can easily validate that my SQL Server infrastructure is configured as expected.<\/p>\n
Code Coverage<\/h3>\n
Code Coverage is the percentage of lines of code that is tested by unit tests.
\nIt’s an indicator of how thoroughly your code has been tested. Having 100% coverage doesn’t mean that the code is bug-free, it just indicates that all your code is being executed during the test.\"\"<\/a><\/p>\n
If I add some code to my Get-ReverseString.ps1 file, the -CodeCoverage functionality will tell me exactly what is not covered by tests:\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
Conclusion<\/h3>\n
This blog post was just to get you started on learning Pester. There are a lot more possibilities with Pester. I might cover some more advanced usages a future post like the TestDrive<\/a> or Mocking<\/a>.
\nHere are some resources I’d recommend:<\/p>\n