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.

Table of Contents – Mocking the Unmockable

With this chapter, we’re right back into unit testing, mocking, and removing dependencies on which our code is reliant. Remember that our last chapter review was on infrastructure validation, which put us in position to ensure dependencies. But not so much today; today we’ll continue our previous, previous discussion on mocking. This time, however, we’re mocking the unmockable, or so they say.

What we learned from this chapter was the ways in which we can mock those times that we occasionally need to drop down and include .NET methods in our PowerShell functions. As Pester cannot yet test this — we hope it’s “yet” — modifications to how we test these things become necessary.

The ways in which we can do this include creating wrapper functions around the .NET method, creating a ScriptMethod — if you’ve never done that, you should try it to say you have; it’s neat — creating a stubbed command, and finally, asserting mocks transitively. This one was described as not being “for the faint of heart.” And the author may be right, as it became a multiple step process. Not terribly difficult in the example; however, it may become more involved in one’s own testing.

The point is clear though, stick to PowerShell at all costs, and only use these options where they are actually required. As the chapter wrapped up, it was indicated to use helper functions — our first of the four options. It’s the easiest of the options, and offered an interesting note. One purpose behind PowerShell was to give system administrators a consistent and usable shell and scripting language. The functions and cmdlets we use are all wrappers around .NET. That was the idea: simply access the features of .NET through PowerShell — a language a system administrator might be willing to use. Great chapter and I’ll definitely keep these options in mind, with a lean toward wrapper functions.

I’m working on the next chapter review of The Pester Book, and I had a thought. I was about to add the first, below paragraph to that review, but it ultimately just didn’t make sense to include it there. And so here we are: a sidebar of thought, I thought I would share.

I want to make mention of my project of writing chapter reviews for each chapter of The Pester Book. While I would recommend trying this yourself, sure, there’s an unspoken balance between sharing and not sharing, what I’ve read and what I’ve learned.

What I mean is this: The book is meant to be purchased, and therefore, the author would expect that while he’s given me permission to take on such an endeavor, he’s done it with what I’ll assume is the expectation that I won’t give away all the book’s secrets. Personally, I think I’ve done a great job in regard to this balance. If one review heavily shares content in the chapter, the next one won’t nearly as much. The purpose of these chapter reviews, like most things on my site, is most definitely dual purposed. On my site, I write for the reader, but I also write for myself, too. If I want to remember something well, and think it would be beneficial to the PowerShell community, then it’ll end up being discussed right here.

Same goes for this book. As I read these chapters, writing helps the reader potentially better understand a concept we’re reading together, for those reading along. For those that aren’t, then potentially, they’ll get themselves a copy and read along one day, and return here for a mostly comprehensive review. I’m also helping myself too. These concepts make more sense when I review them; when I force myself to document what I’ve read. And that’s what I’m doing here, reinforcing what I’ve learned for the beneficial purpose of both you, and me. Now back to that next chapter review.

Table of Contents – Infrastructure Validation

This chapter is the one I’ve been expecting all along, and that’s most likely due to it being a selling point of Pester, in my opinion. That’s infrastructure validation, or infrastructure testing, and I’ve seen it discussed in several blog posts prior to its chapter breakdown here. This testing had its hand in how I first used Pester, and I believe it’s one way to get people uninterested in Pester, interested in Pester.

When I started my chapter reviews on The Pester Book, I did so with a story of how I had previously used Pester. You can read it in my introduction post. It discusses the need to verify multiple settings on a work group server in AWS. As we didn’t have Active Directory, a good deal of settings required automation and instead of manually checking that my automation had done what it was supposed to do — which just seems weird anyway — I used Pester to verify my systems were built out as expected. It was a moment in which I was proud, and a part of ensuing that I would know Pester, as well as I can one day. The whole did-it-actually-do-what-it-was-expected-to-do mentality, is a bit of shift after the first 14 chapters.

This chapter does that same thing — automated checking and verification — but does so as it steps away from what we’ve been learning all along. We’re not worried about breaking external dependency, such as we do with unit testing, and instead we need to test that dependencies are actually in place. If we’re creating users in Active Directory, we need Active Directory. If we’re using a CSV file of users to create, we need a CSV. Even more, we need to know that the file contains the data we’re expecting. All these things, are the dependencies we require in order to create the users in the directory. This was in fact the example used by the book, and it was a helpful breakdown of this entire process.

What’s interesting, is that when I think thought infrastructure, I often considered hardware, or at least VMs. Like, real honest pieces of infrastructure. I didn’t actually think of users, and therefore, this chapter’s example was beneficial, as infrastructure can in fact be users. I can buy into that, especially in relation to infrastructure testing.

And now, moving along. We have a couple more chapters in this part of the book.

Update: I located an image of the Pester testing mentioned here and in my introduction post, as well. It’s been included below. It took only 950 milliseconds to completely check that my machine was built property. It checks for Registry entries, a certificate, PowerShell modules, and more. I couldn’t even do the first test manually — checking for a Registry subkey — in that amount of time. I’d be lucky if the Registry would even open in under a second.