At one point or another you’ve probably heard of Pester. Pester is great for streamlining unit and acceptance testing and is versatile enough to work with both real and mock data. The problem I’ve often run into is knowing when (and when not) to leverage Pester to create additional tests. For me, it came down to asking myself 1 thing… Does the underlying technology that your code is built upon constantly change?
For example, in my environment I do a lot of scripting for VDI and Configuration Manager. Both of these environments receive constant updates and any one of them could break your entire codebase. You need a way to quickly and efficiently QA your code after any change request, and Pester is exactly what can do that for you.
Once you’ve come to accept that you need to write additional code to test your existing code, usually people ask themselves, what now? Like all new things it often isn’t wise to jump in head first, so start small. For example I have a basic script that our help desk uses to initiate software update scan actions via Config Mgr on a remote machine. I started by writing a Pester test to simply check service names. Then I built upon that by ensuring the action I was initiating was still valid. Now after any update on both the MPs and Clients I can quickly validate that my code still functions as intended. Again, this is a very simple example but imagine having an entire toolset of scripts that are impacted by environmental changes like this. It would be very tiresome to have to test all of that code constantly, or worse play firefighter and just wait for something to break. In today’s day and age I think we need to be as least reactive as possible, so it makes a lot of sense to implement proactive practices such as this one.
Check it out at: https://github.com/pester/Pester