How I Work: Pester Testing

Ever since the 2015 North America PowerShell Summit I’ve become addicted to Pester testing. I use it for Unit Testing as well as Operational Validation. Not only the Pester open source but it is actually included in Windows 10. The rumor at the summit was that this was the first open source software built into Windows. This is truly a new Microsoft.

I also use Generic Pester Tests to make sure my code stays up to my standards. Exported functions should have great help. Modules should be able to pass automated tests for publishing and consistency purposes. A constant reminder that your code won’t be able to be published from the PowerShell Gallery or that your code is currently without help really motivates me to do better.

TDD

I now follow the Test-Drive Development (TDD) method for producing my PowerShell code. I prototype my function enough to get it to show up in an automated Pester test, write the Pester tests to define my inputs and outputs of my new function, then write the actual function. This forces me to think before I type. I have to know exactly how the function will perform because I have already defined it’s interface through the Pester tests.

To make sure I’m accomplishing all of my goals enforced by Pester I add a second console window to my ConEmu window that simply runs Pester tests on loop. To get the tests to run on file save I use PowerShell Guard written by Steven Murawski and run the following command after it is installed.

New-guard -Path Git:\CIUtils\ -Recurse -TestCommand Invoke-Pester -Wait

When I work I usually open up a smaller console window inside of ConEmu and whenever I change I file it kicks off the specified tests.

Now, after ever change I make to code I get the instant feedback if one of my changes broke any of the functionality expected from my functions. This keeps me from investing time solving problems that I don’t need to solve. If I fail a test, I go and fix it. I don’t find out hours later that I introduced a breaking change then built on top of that bad code. It forces good habits and has served me well while creating PSPushover.

What does your process look like when you write your code?