The Pester Book: The All-in-One Guide to Understanding and Writing Tests for PowerShell

281 Pages·1.199 MB·English

by  Adam Bertram

The Pester Book (Kindle Version)

Adam Bertram
2
The Pester Book (Kindle Version)

Adam Bertram

This book is for sale at http://leanpub.com/pesterbookkindle
This version was published on 2020-03-17
* * * * *
This is a Leanpub book. Leanpub empowers authors and publishers with the
Lean Publishing process. Lean Publishing is the act of publishing an in-
progress ebook using lightweight tools and many iterations to get reader
feedback, pivot until you have the right book and build traction once you do.
* * * * *
© 2020 Adam Bertram
3
Table of Contents
About the Author
Foreword
Feedback
Code Samples
Introduction
Testing as Institutional Memory
Testing Drives Better Modularization
Tests as Functional Specifications
Tests in Automated Build Pipelines
Where We’re Not Going
Resources
Part I - Pester Concepts
Block Introduction
Describe Blocks
Context Blocks
It Blocks
Before and After Blocks
Summary
TestDrive and TestRegistry
Using TestDrive
Using TestRegistry
Summary
Assertions
Using the Should Assertion
Understanding Should Operators
Testing Collections
Other Tests
Testing Errors
4
Adding Custom Assertion Operators
Because
Summary
Test Cases
Creating Tests for Different Parameters
Using the TestCases Parameter
Using the Test Name Token
Summary
Mocking Introduction
Mock Walkthrough
Mock Assertions
Summary
Code Coverage
Why Code Coverage?
Using Pester to Measure Code Coverage
Getting Granular with Code Coverage
Summary
Gherkin
Files
Features
Scenarios
Steps
Step Definitions
Running Gherkin Tests
Summary
Part 2: Using Pester
Controlling Test Results
Pending and Skipped States
Forcing Pass/Fail States
Summary
Working with Pester Output
nUnit XML
Returning Failed Tests as Exit Codes
5
Summary
Tagging
Introduction to Tagging
Tagging Strategies
Summary
Modules and Dot-Sourced Script Gotchas
Scripts with Functions
Modules
Summary
Advanced Mocking
Mocking Specific Object Types
Mock Scope
Module-Level Mocks
Parameter Filters
Summary
Mocking the Unmockable
.NET Methods
Creating Wrapper Functions
“Overwriting” .NET Methods with a ScriptMethod
Using “Stubbed” Commands
Asserting Mocks “Transitively”
Summary
Improving Code Coverage
Step #1: Getting a Baseline
Step #2: Build the Test Framework
Step #3: Create the Mocks
Step #4: Know the “Before” Code Coverage
Step #5: Build all Tests
Step #6: Re-check Code Coverage
Summary
Infrastructure Testing
Analyzing the Code
Getting Testing Dependencies in Place
Prototyping the Infrastructure Tests
6
Assessing the Current Environment
Writing the Infrastructure Tests
Dependencies
Operational Validation Framework (OVF)
Summary
Troubleshooting and Debugging
Sending Variables to the Console with Write-Host
Using Debugger Breakpoints During Tests
Summary
Test Walkthrough #1
Analyzing the Code
Refactoring
Deciding What to Test
Find the Shortest Code Path
Creating Test(s) for the Shortest Code Path
Building Tests for Other Code Paths
Summary
Test Walkthrough #2
Understand the Subject
Designing Tests
Writing the Tests
ImportVariables Parameter
ImportModules Parameter
RunspaceTimeout Parameter
Parameter parameter
Summary
Part 3: Hands-On Design and Testing
Buildling Testable Code
Modularization
Limit Function Input
Input Via Parameters
Managing Output Properly
Summary
Test Design Practices
7
Ensuring Code “State” Doesn’t Change
The Input/Execution/Output Pattern
Choosing When to Create Describe Blocks
Naming Conventions
Summary
Part 4: Pester Cookbook
Recipe: Testing for Live Conditions
Recipe: Testing for Installed Software
Recipe: Ensuring all Functions in a Module Have Tests
Recipe: Testing External Applications
The Background
Testing Exit Codes from Standalone EXE files
Recipe: Testing Syntax
Recipe: Testing Remote Script Blocks
Resources
Video Courses
Articles
8
About the Author
Adam Bertram is a 20-year veteran of IT and experienced online business
professional. He’s an entrepreneur, IT influencer, Microsoft MVP, blogger at
adamtheautomator.com, trainer and content marketing writer for multiple
technology companies. Adam is also the founder of the popular IT career
development platform TechSnips. Catch up on Adam’s articles at
adamtheautomator.com, connect on LinkedIn or follow him on Twitter.
9
Foreword
Years ago, when I started writing PowerShell, I felt a spark. It was one of
those sparks that get you excited to go to work. It was a spark that activated
my inner geek and gave me an excellent sense of accomplishment after I had
automated something. That spark has since turned into a fire which has
energized practically my entire career. PowerShell is now a big part of my
work life.
This is what Pester feels like. That’s big!
Pester is a product that’s gotten me probably too excited sometimes and made
my eyes light up with satisfaction when I see all of that lovely green output
scrolling down the screen to confirm the success of my code.
As I’ve worked with Pester over the years, I always performed a TDD-hybrid
approach with it. TDD is writing failing tests first and then only writing the
code that makes the tests pass. In a previous life, I was a Senior Automation
Engineer using PowerShell, which, in a roundabout way, is the same thing as
a PowerShell developer. I worked on code that provisioned test environments
for my developers as well as code for projects for clients.
Before Pester, I would write thousands of lines of code, run it, fix it, run it, fix
it, run it ad infinitum. It “worked” for the most part until some unknown bug
crept in or someone else on my team made a change I wasn’t expecting, and it
would break. I’d then have to dive in and spend time researching, fixing, and
sometimes breaking other things in the process. At the time, I thought it was
just how you wrote PowerShell code. I was wrong.
I thought that testing—and thus Pester—was a waste of time. Why would I
want to essentially to write the same code again to confirm I wrote the code in
the first place? To me, it was a huge time drain for little value. That is until I
decided to buckle down and force myself not to write a single line of code that
wasn’t covered by a unit test.
This is my story.
10