This document provides an overview of how to use Pester to test PowerShell code. Pester allows you to write unit tests for PowerShell scripts and functions. Tests are organized using Describe, Context, and It blocks. Describe blocks group related tests, Context blocks divide tests by scope, and It blocks define individual tests with inputs and expected outputs. The document includes examples of using Should statements to make assertions and leveraging Pester with build systems like AppVeyor for continuous integration. Resources for learning more about Pester and unit testing PowerShell code are also provided.

1. 1
How to
Test PowerShell Code
Using Pester

2. 2
Chris Wahl
Writer
Co-Host
Instructor
Technologist
Author
Microsoft
VMware
@ WahlNetwork.com
@ DatanautsPodcast.com
@ Pluralsight.com
@ Rubrik.com
Networking for VMware Admins
MVP (PowerShell)
VCDX #104 (DCV & NV)
Get-Person

3. 3

5. 5
Pester … what?

6. 6
Drivers for Change
• You want to test your scripts for bugs
– But you feel bad making other humans do this for you
• You freely admit and acknowledge that testing isn’t
possible with your own meat spatulas
• You also like to automate stuff to avoid more work

7. 7
How Pester Helps
• You write one or more unit tests
• Pester executes them
• The tests either pass or fail
• Results are displayed

8. 8
Example 1
Given an input of $false
You expect a return of $false

9. 9

10. 10
What Happened?
• The function was evaluated
• The return value was $true
• Pester uses the “Should Be” to compare against $false
• These values don’t match
• The test fails

11. Let’s Dig Deeper into Pester

12. The Describe Block
• This is your logical grouping of tests
• It’s also a testing scope
– You can define “mock” commands within this scope
• Child objects:
– Context = a group of “it” tests
– It = a single test

13. 13
The Context Block
• A way to logically divide your Describe blocks
• Ex: Run tests under one context / account, then repeat
using a different one
• Ex: Test using a “user” account and then again using a
“super user” or “admin” account
• Ex: Start with a relative path and then a strict path

14. 14
The It Block
• This is where you run a specific test
• One set of inputs, one set of outputs
• Don’t get all fancy pants
• Use the Arrange-Act-Assert format
– Get data
– Test it
– Make sure it ran (code coverage)

15. 15
Describe, Context, and It
• Describe … a group of API specific tests
– Context … a group of tests against an old API version
• It … runs tests against function1
• It … runs tests against function2
• It … runs tests against function3
– Context … a group of tests against a new API version
• It … (repeat tests from before)
• Describe … a group of parameter tests
• And so on …

16. 16
Example 2
Using “Should” in a variety of ways

17. 17

18. 18
Example 3
What if you can’t use the real code?

19. 19

20. 20
Example 4
Leveraging Pester with other build systems

21. 21
• Many systems can leverage Pester tests
• AppVeyor is a popular CI / build system
– https://ci.appveyor.com/project/brianbunke/confluenceps
– http://wahlnetwork.com/2017/04/18/version-and-publish-
powershell-appveyor/

23. 23
Closing Remarks and Resources

24. 24
Thoughts
• Keep your functions as small as possible
– I prefer one logical statement per function
• Unit test the functions rather than the workflows
• Embrace TDD and creating tests for everything you do
• As you encounter an issue, build a test for it
– That way it never happens again
– Crush tribal knowledge!
• Be kind to your future self

25. 25

26. 26
Resources
• Pester
– https://github.com/pester/Pester
• The Pester Book
– https://leanpub.com/pesterbook
• PowerShell Summit “Lightning Demos”
– https://github.com/RamblingCookieMonster/CommunityLightning
Demos2017
• xUnit Test Patterns: Refactoring Test Code
– http://amzn.to/2pcaKQK

27. PowerShell / Pester Twitter Folks
27
Chris Hunt
Twitter: @logicaldiagram
Adam Bertram
Twitter: @adbertram
Jeffrey Snover
Twitter: @jsnover