Table of Contents – Introduction

As a reminder, as this is only the second post in this series, we’re about to begin a chapter review on The Pester Book. I would encourage you to get yourself a copy, if you haven’t already. Read your copy along with me and mine, and then head back here for chapter reviews. As mentioned once thus far, I’m not out to teach you Pester per se. That’s what the book is intended to do. Instead, I’m going emphasize the main points of each of the chapters. I’m going to write as though we’re reading the same thing at the same time. I have no idea if it’ll work, but I was confident enough. If you’re not reading along now, then use it when you are, or use it motivate yourself to do it at some time. Just don’t waste too much time, telling yourself you’ll eventually learn it.

I recently finished reading the Table of Contents through the Introduction and the introduction’s various parts. This means that I’ve covered the up front information — the about the author stuff, the foreword, how annoying code samples can be in “print,” and how to provide feedback. I’m actually appreciative that Adam’s willing to hear from the community about typos, code problems, and the like. As this is forever book, or living document, if you will, we can each be a part of ensuring its accuracy.

As you’ve seen, if you’re reading along, the book is broken down into five parts. These include Meet Pester, Using Pester, Using Gherkin with Pester, Code Coverage, and Pester Cookbook. Each part has anywhere from a single included chapter to several. These are pieces we’ll cover together, no matter how simple and short, or involved. I’m very grateful for the upfront, hey-let-me-introduce-you-to-Pester section. I get the feeling, the book isn’t out to make any assumptions that anyone of us already knows a portion of this content, even if we might.

I also get that same feeling from those introduction sections. The book briefly discusses the differences between unit tests, integration tests, regression tests, and the occasional acceptance test. Right off the bat, we’re getting a break down of the testing structure and type, and their logical order. It’s enough to get you excited to continuing reading; it was me, anyway. Now, it’s just me putting it to memory: unit, integration, regression, and acceptance.

As mentioned, testing isn’t new, but it may be to (some of) us. The whole Windows administrator turned scripting experts is still somewhat new on the Windows end. For me, I loved VBScript, back before PowerShell was even a thing. Back then, things were different though. You didn’t have to know VBScript to be a Windows system administrator. But now, 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. That’s my prediction, anyway.

Before I wrap up here, I do want to mention the four paragraphs about testing that were included toward the end of the introduction. Those were highlighted as Testing as Institutional Memory, Testing Drives Better Modularization, Tests as Functional Specifications, and Test in Automated Build Pipelines. All very simple and short, yet important and relatable. See you again next time.