Summary: Guest blogger, Dave Wyatt introduces a new test framework for PowerShell called Pester.
This week we are honored to have one of the authors of Pester here with us on the Hey, Scripting Guys! Blog. It’s Dave Wyatt himself, a Cloud and Datacenter MVP. Dave, tell us all about Pester…
What is Pester?
That’s easy to answer…
Pester is a test framework for PowerShell. It provides a language that allows you to define test cases, and the Invoke-Pester cmdlet to execute these tests and report the results.
Why should I care?
That’s a more involved question if you’re new to DevOps in general. One of the core practices used in successful DevOps shops is automated testing (which is part of the larger practice of continuous delivery). The idea is that every time someone checks in a new piece of code to source control, it is automatically put through a series of tests (which are also in source control, along with the code being tested).
If the code passes all of the automated tests, it becomes eligible for additional manual testing (if desired), and it is then a release candidate for production. Although it takes some time investment to write and maintain all of these automated tests, you more than make up for it by getting through the test process faster and without human interaction.
This allows you to release code much more frequently and to detect and fix errors much earlier in the process (where it tends to be less expensive). Have you heard of agile software development? This is part of that approach.
One of the coolest things about PowerShell is that it can act as a “glue language” between other technologies. From a PowerShell script, you can easily access the .NET Framework and CIM. With a bit more work, you can also interact with lower-level native code (such as Win32 API).
With Export-ODataEndpointProxy, New-WebServiceProxy, Invoke-WebRequest, and Invoke-RestMethod, you can interact with web APIs. Because Pester tests are simply PowerShell code, this means that you can use Pester to test all of these things, even if they’re not actually written in PowerShell.
Why does this matter to us IT folks?
Traditional IT practices just can’t keep up with the pace of agile software development. I’m sure you have heard about “DevOps” at some point in the last few years. One way of interpreting DevOps is simply taking the best agile practices and applying them to the IT side of things.
Instead of taking weeks or months to procure servers, and manually install and configure them to get them ready for software deployments, we move toward virtualization and the software-defined datacenter. Builds of virtual machines become automated, and all of the information needed to rebuild your entire environment is stored in source control. (This is referred to as “Infrastructure as Code,” incidentally.) Configuration management tools such as PowerShell Desired State Configuration are part of this infrastructure definition.
As IT pros start to write and use more DSC resources and configurations, we’ll need to test them to make sure everything is production ready, and that’s where Pester comes in. This is so important to successful cloud-scale IT that Microsoft and VMware have actively been using and contributing to Pester for the last several months, instead of pursuing their own internal test frameworks. Microsoft shipped a copy of Pester in Windows 10.
Hopefully, this has piqued your interest! Over the rest of this week, I’ll be covering all of the essential parts of Pester that will enable you to write tests that can help speed up deployments while maintaining a high-quality infrastructure.
I’ll leave off with a quick example of a Pester test script. To make this all fit into a single screenshot, I’ll just define the PowerShell function being tested and the Pester tests in the same file, though these would normally be stored separately. Tomorrow, we’ll take a closer look at the contents of this example to learn more about how Pester works.
~Dave
Thanks Dave! We’re looking forward to hearing more about Pester tomorrow!
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy