Most of you probably know that I’m a big fan of automated testing and especially testing during the development process. It significantly improves the design of the code by encouraging loose coupling and high cohesion. It also provides great documentation and increases the confidence of anyone who needs to change the code in the future (this includes future you)!
Wilsons Corollary: If your code is hard to test, it is probably not following good design principles.
Many PowerShell Scripts are Critical
As DevOps processes mature, the automation of tasks related to builds, deployments, and support tasks has significantly increased. Much of this automation is accomplished using shell scripts. If we’re working in the Microsoft ecosystem, we’re writing a lot of this automation using the PowerShell scripting language. However, in many cases we’re not treating them as full-fledged code artifacts. This means they may not be source controlled, scanned for correctness, security scanned, or unit tested.
Many times these scripts are used to automate critical operational tasks including builds, deployments, infrastructure creation, patching, and much more. Having reliable scripts and reusable scripts is critical to scaling these types of operations and sharing this knowledge with the across IT teams.
If you want to find out how important an automation script is to a team, just make a small breaking change to it and see what happens…
Pester Testing Framework
The Pester PowerShell framework was created in 2010 by Scott Muc
The 3.0 version of Pester is included by default in the installation of PowerShell. However, there are more recent versions available in the open source community. To get the best experience with Pester, it’s recommended to upgrade to the latest version. Currently the major version is 5.0. For information on installing and documentation about using Pester there are some great resources in the documentation.
I’ve found this framework to be an invaluable addition to my PowerShell toolbelt. Being able to test PowerShell has provided a lot of confidence in the scripts and modules that I’m creating and gives me the confidence to publish them for others to use.
Happy PowerShell Testing!