Update: As this project is now complete, I’ve updated the publish date on this Table of Contents post, in order that it comes before (really, it’s after), all 23 of my chapter reviews.

Welcome to The Pester Book Chapter Review, Table of Contents (ToC). Use the below links to read my chapter reviews. If this project isn’t yet completed, you can check back for updates every week, at most. Once done, however, the links will remain so you can read my chapter reviews, as you read the book. If you’re writing PowerShell and haven’t started testing your code, it’s probably time you did.

“…you really should know PowerShell, and if you’re going to have to learn it and write it, then let’s learn to test it, too. Pester is going to be one of those things, that in time, people will assume you know, if you know PowerShell…”
-Tommy Maynard

My Introduction
The Introduction

Part I: Meet Pester

Pester Concepts
Designing for Testing
Describe Blocks
Before and After Blocks
It Blocks
Should
Test Cases
Mocks
The TestDrive Drive

Part II: Using Pester

Design Practices
Adding Tests for a Function
Adding Tests – Again
Working with Pester Output
Infrastructure Validation
Mocking the Unmockable
Troubleshooting Tests

Part III: Using Gherkin with Pester

Using Gherkin with Pester

Part IV: Code Coverage

Why Code Coverage?
Using Pester to Measure Code Coverage
Improving Code Coverage

Part V: Pester Cookbook

Recipe: Testing for Live Conditions
Recipe: Testing for Scheduled Tasks
Recipe: Testing for Installed Software
Recipe: Ensuring all Functions in a Module Have Tests
Recipe: Testing External Applications
Recipe: Testing Syntax
Recipe: Testing Remote Scripts Blocks
Other Resources

Table of Contents – Part V: Pester Cookbook

Well, this is it. We’re just about done with this project in its entirety. That’s right, we’ve come to the end of The Pester Book chapter reviews. Originally, I was going to do one post per recipe in this section; however, there’s so little to discuss on each that it makes more sense to wrap things up in a single post. And, so here we are.

These recipes, as Adam as chosen to call them, are little, bite-sized mini chapters that discuss a quick topic one might encounter while testing. I especially enjoyed them in that they included simple functions and a simple, corresponding test, or tests. We covered testing for live conditions where we compared a function’s internal WMI call against the actual WMI outside the function, we tested for installed software, determined a way to ensure all the functions in a module have a test, we tested exit codes from executable in scripts, we tested external applications in conjunction with the $LastExitCode automatic variable, we tested syntax errors (think exceptions), and how to handle remote script blocks — that was important to see.

In closing, Adam shared other Pester related resources. There were some I’ve already seen and used, and others I haven’t. I’m not as confident as I’d like to be (and that’s a common theme with me), but after reading this book, I’m armed with enough information to have meaningful conversations about Pester, as well as starting to write more test suites, even as I may need to use Pester included help and the Internet, as I do. It was a good read, and certainly brought me to a new high in my Pester testing knowledge.

Therefore, if you’ve been reading along and learning with me, then we’re both at a better place, as new coding ideas and opportunities start with what do we test, before anything else. I don’t know about you, but I’m looking forward to that next project.

Table of Contents – Improving Code Coverage

This, was a very involved chapter, and it required a good deal of concentration. We first had to understand a good amount of PowerShell that we then had to write tests around. Even so, this turned out to be a great opportunity in that we had not typically seen some of the examples that were included in this chapter. We saw multiple mocks for the same command, mocks that included New-MockObject, a good deal of ParameterFilter parameters on our mocks, and even a Foreach around an Assert-MockCalled command. Awesome.

All that said, the idea behind this chapter wasn’t to present various ideas for testing — although it most certainly did — it was to do a full code walkthrough in regard to code coverage. Once we understood the example function, we met three initial tests someone new at Pester might write. Then the example took off, with a whole new test suite written by Adam. After a multiple page understanding of what had been written, we tested the code coverage. It wasn’t perfect, but it was close. A few changes and we got to a place where the percentage was high enough to feel confident that everything in this function had been tested.

There was a quote I liked, I’ll share in closing. I liked it because we got an image that just like you or me, Adam walked the code in his own mind and extracted those things in which he wanted to test. “These tests were created by following the various code paths of the function. I followed the code from top to bottom and when it “did something,” I created a test for that thing. I followed all code paths.”

Well, next we’ll start Part V, and work to wrap up this chapter-by-chapter book review. I’m excited to finish, but mostly so I can head back and review a touch before I find my next Pester resource. I don’t feel like I know it, know it, so like PowerShell before this, I’ll keep looking for new information to consume in regard to Pester. Back soon.

Table of Contents – Using Pester to Measure Code Coverage

Oh man, this was good. This chapter was short, simple, and to the point. In it, we used Pester to measure our code coverage. If you didn’t know this feature was included in Pester, then I suspect you’re grateful now. You should be, as for me at least, I can easily see how this can be helpful. Providing you use it correctly, and get a grasp on what it’s testing and whether it’s testing, then there’s definitely going to be some benefit here.

We discussed a few scenarios during this chapter. These included executing a simple code coverage test — so we could see how this thing works. We saw how Pester will notice untested functions, how Pester will indicate full coverage even if a test doesn’t include an assertion, and how to force a test against a single function, even if there’s more than one in a single .ps1 file. In addition, we saw how we can test a single function by including line numbers for the function, instead of providing the function’s name.

I suspect this was a great intro and build up for the upcoming, and final chapter, in this part of the book. The next chapter looks involved. Time to get started.

Table of Contents – Why Code Coverage?

Welcome to Part IV: Code Coverage. I read this chapter in the most recent version of The Pester Book, which was released on Saturday, April 28, 2018. Be sure to get the newest version if you’re following along. I hope you have been, as according to the ePub file on my iPad, Part IV began with only 51 pages left in the entire book. We’re nearing the end.

Code Coverage is the ability to determine the amount of code that executes as a part of your testing. There are a few metrics, or measurements, that we use along with code coverage. These are statement coverage, branch coverage, path coverage, and condition coverage. Each of these allow us to measure the coverage of code, even as they may sometimes overlap. Be sure to make these, make sense to you.

It was nearing the end of this shorter than normal chapter when it spelled it out like so: “Simply put, code coverage is a way of measuring whether or not you’re executing all of your code through a given set of tests.” In closing here, I do want to bring up test cases. As they were mentioned as a part of this chapter, you may want to head back and review theses if you don’t remember them well. I remember them, but that’s because I’ve put them to use in some of my own testing.

I’m already looking forward to the next chapter, where I’ve spotted some example code. It’ll be helpful to see some examples after this introduction.

Table of Contents – Using Gherkin with Pester

It turns out there’s this whole thing called Gherkin. Before this chapter, all I knew is that I liked saying Gherkin, but that I didn’t really know much else about it (besides the whole cucumber/pickle thing). This single part of The Pester Book had just a single chapter in order to introduce us to Gherkin. I’m not going to try and explain it exactly. What I’ll do instead, is allow the book to partially do it for me. Here’s a quick couple of sentences from the text:

“Gherkin is a Business Readable, Domain Specific Language. It’s meant to decouple the business logic from the actual code being tested. It’s a language that can be used with any development language thus how we’ve been able to use Gherkin with PowerShell and Pester.”

That’s kind of neat, the whole, it can be used with any development language. I guess that’s why it’s in here. I did want to mention that Gherkin appears “…to be more suited for infrastructure testing rather than unit testing.” That’s probably a good thing to know.

Gherkin requires two files. There’s a .feature file and a .steps.ps1 file. One holds code, and one does not. The layout of these two files are specific in that the .feature file contains text description of how the tests will be structured (no code). The actual code — the tests — are located in the steps.ps1 file. These should be kept together inside the same directory with the script, or module, that is being tested. I won’t go into the layouts of each of the files, but it was certainly interesting to see, how each file was dependent on the other in order to execute the code — the tests. You’ll be glad to know that embedded within the .steps.ps1 files was PowerShell, and Pester, used to test the expected vs. the actual results.

I would recommend you work through and understand the example in the chapter. I didn’t really want to at first — I’m doing Pester, not pickle — but in the end, I’m glad I had some exposure to Gherkin, just in case it comes up another time.

Table of Contents – Troubleshooting Tests

Welcome to the last chapter review of Part II of The Pester Book. We’ve come along way since the beginning. Even the book would agree. According to this chapter, our “training wheels are off…” This is to say that we know some things about Pester now, and really, after all this reading and the overall learning, it’s no surprise. Let’s, “…get down to it.” The purpose behind this chapter isn’t to teach, as much as it’s to determine what we might be able to do as we have problems with Pester.

At first we touched on the option to add a variable inside your script to determine its value during run time. While there’s probably better ways to handle this, we checked our variable’s value from inside the test instead of inside the function. Good to know that the ParameterFilter parameter is just a ScriptBlock, and so we can view the value there. The book agreed there are better ways in which to troubleshoot our tests.

We then moved into breakpoints. This is the more official, and grownup, way to track the values of variables. That said, the example in the book opted to set a breakpoint on a command. That meant that when the command was invoked, the code process stopped in order that we were able to determine the value of a variable right then.

Great stuff, but now, it’s time for Part III. That’s right, Part I and II are officially read and reviewed.