Devops – Unit testing in Powershell Part 2

Powershell has really gained a strong momentum the last 3-4 years and is becoming increasingly the scripting language of choice if you live in the Windows part of the IT world. Together with the increasing popularity of the Devops phrase, unit testing is a key factor going forward.

This is part 2 (Part1) of a small series of posts related to unit testing in Powershell. You can read the first post her.

In the previous post we presented the Scenario we will be working with and the API functions that our SillyModule will wrap logic around.

The tasklist

1. Read up on Unit Testing frameworks for powershell (Pester or PSUnit)
2. Create the the SillySystem Import-Object and Export-Object API
3. Walk through of the module and the functions (Get/Update-Person/Group)
4. Create tests for the functions
5. Refactor where needed ad update the tests

The SillyModule

The context of the module is pretty simple. We need cmdlets to receive a list of persons or groups. The list may be filtered on a specific property (Name or ObjectID). Next we need cmdlets to update/modify the properties of a person or group. Currently our module does not support adding or deleting objects.

Functions exported from the module:



To additional helper functions added that we have not talked about.

• Get-Object – Is a wrapper for the Export-Object command/API. All cmdlets with verb Get calls this where the xPath is built for Export-Object.
• Remove-HashtableNullValue – Is a helper function that removes keys from an hashtable that contains $null values. It is used in the Get-Object function.

To better understand how the cmdlets works, I have created a very simple flow chart for Get-Person and Update-Person.




The SillyModule and SillySystem are both available on GitHub:

• SillyModule
• SillySystem

Clone them or download them from GitHub to play around and see how they work. Run the build.ps1 script to build the module.

Our first test

Please bear in mind that I am not an expert on unit testing and I urge anyone with experience and knowhow to guide us if I make the wrong turn. If you have not done it yet, clone or download the Pester module from GitHub.

I usually start in the middle of the call stack, that is as close as possible to the functionality that is not under my control. In our scenario that would imply that we should start with Get-Object function.

The Pester module comes with a function to help you get started with testing. It is called New-Fixture. It will generate 2 files:

• One file for the function you want to develop (Test Driven Development remember)
• One file that will hold the tests for the function. This scriptfile will contain some startup magic to make pester run its test and a dummy test for the function.

What happens if we run this:



New-Fixture will output an warning and inform us that it found a file called Get-Object.ps1 and skip the creation of it, but the test file will be created and called Get-Object.Tests.ps1:



Sweet we have our test file. Lets crank it open in ISE and have a look:

psedit .\functions\Get-Object.Tests.ps1



Turns out a Pester unit test is just a script file with some magic and keywords that describe (duh) the unit tests. Notice the red arrow and the . (dot). Pester dotsource the Get-Object.ps1 file which contains our function Get-Object into the script scope of the test. If you don’t know what dotsourcing is, look it up it is out there.

There are some rules. In my testing I use three keywords: Describe, Context and It. 

1. A test file can have multiple Describe scriptblocks. 
2. A Describe can have muliple Context blocks and It blocks
3. Context- and It blocks must be contained within a Describe scriptblock

Now to the fun part. The It block contains the actual testing. In our current test is says that $true should be equal to $false. No need to say that this test will never pass in it’s current form. To run a test-file, we use the Invoke-Pester cmdlet and give it a test file. Lets run it and confirm:





It says it expected the value to be False, but it was True. Change the test to $true | Should be $true, save the testfile and run it with Invoke-Pester:





There it passed the test, which should come as no surprise to you. It is a silly test for a silly module! Time for some more realistic testing for our Get-Object function in the next part.

Cheers

Tore