Recently at work I have finally seen the light and begun adding Pester tests to my modules. Why is this a recent thing, you may ask? After all, I was at PowerShell Summit and heard the good word about it from Dave Wyatt himself way back in 2015, I’ve had years to start doing this.
Honestly, I didn’t get it…
To tell the truth, I didn’t understand the purpose of Pester. I always thought ‘Why do I need to test my code? I know it works if it accomplishes the job it’s supposed to do’.
For instance, I understood that Pester was a part of test-driven development, a paradigm in which you start by writing tests before you write any code. You’d write a ‘It should make a box’ test and wire it up before you actually wrote the
New-Box function. But I was only looking at the outside of my code, or where it integrates into the environment. In truth, all of the tests I wrote earlier on were actually integration tests.
See, Pester is a Unit Driven Test Framework. It’s meant to test the internal logic of your code, so that you can develop with certainty that new features to your function don’t break your cmdlet.
CodeCoverage made Pester finally click
It wasn’t until I learned about the powerful
-CodeCoverage parameter of Pester that it actually clipped. For instance, here’s a small piece of pseudo code, which would more or less add a user to a group in AD. Continue reading