Table of Contents – It Blocks

Today, we’ll review some of what was offered by the It Blocks chapter. Things, are getting interesting.

It turns out that It blocks are our main unit for testing. These blocks are the smallest blocks and belong inside a Describe and/or any Context blocks, if you’re using those. As they’re the smallest, it’s always best to keep them “simple, and as straightforward as possible.” The idea was that we should test everything independently of each other when we can, and that when we can’t, there needs to be a good idea as to why. That lead me to this write this Tweet today, where I questioned whether I should test all the permitted random password length values (4 – 35), that my random password function would accept in a single test, or one test — one It block — per value from 4 – 35. Take a look and let me know what you think as I’ve done both below. I haven’t actually seen any replies yet besides a few likes, and I still don’t know which I’ll end up using.

Which would you do? Test all the permitted random password lengths in one #Pester test, or test the permitted length in individual tests? #PowerShell pic.twitter.com/tawx4erUEA

— Tommy Maynard (@thetommymaynard) March 26, 2018

We also learned to have your It block throw a terminating error if an expectation isn’t met, the five possible results of an It block (passed, failed, etc.), using the Pending and Skip parameters on our It blocks, and finally about the Set-TestInconclusive option for It blocks that ensure a test is never run, under any circumstance.

Next we’re talking about Should. That should be interesting.

Table of Contents – Before and After Blocks

If for some reason you’re just getting here now, we’re doing chapter reviews on Adam Bertram‘s The Pester Book. Get a copy, start reading, and follow along with us. It’s the PowerShell testing framework, and you’re going to need to know it, if knowing PowerShell is something you already need to know.

Today we’re going to review a good, but short chapter on Before and After blocks. Before and After blocks contain two blocks each. Those are BeforeAll and BeforeEach, and AfterAll, and AfterEach.

BeforeAll and AfterAll blocks indicate things that should happen before any of the It blocks run, and after all the It blocks run, respectively. The difference with BeforeEach and AfterEach, is that whatever arbitrary code runs in these, does so before and after each It block, and not just once at the beginning and once at the end of a Describe and/or Context block.

Got it.

Table of Contents – Describe Blocks

And, here we go. It’s time, to start testing with Pester. Or rather, it’s time to really start making our way toward that end goal. We’re going to start that with Describe blocks, also known as, “…the outer container for a group of tests.” It’s how this whole testing thing begins, and it looks like this:

Describe {

}

As stated, we need to think of a Describe block as a single shared scope for everything it contains. This means that the TestDrive PSDrive is available to all the tests within the Describe block. But what’s the TestDrive, right? I think it may have been mentioned previously, but it’s a drive — a PSDrive — that exists while the Describe block is executing. It’s a place to safely create folders and files during testing without the fear of making any mistakes against actual files and folders. There was also a mention of Mocks only existing while the Describe was running; I suspect we’ll get to these in time.

This chapter also touched on a few other valuable concepts that we’re going to be grateful we’ve learned. These included tagging. The Describe keyword actually has a Tag parameter that can be used to help separate whether, or not, a Describe block will run when using the Invoke-Pester function — don’t think we’ve talked about that one yet. Do keep in mind that if you don’t include a tag for a Describe block, that it’s always going to execute when the test is run.

This chapter also clued us in to upcoming topics, which included the Context block, It blocks, and BeforeAll, BeforeEach, AfterAll, and AfterEach. Keep reading; I’m about to do the same.

Table of Contents – Designing for Testing

In this chapter, we learned that Pester is going to make some assumptions about the code that we write. Therefore, in my mind, it’s going to be best if we learn what Pester is expecting and do that — well, those of us reading The Pester Book, at least.

This means we need to work with .ps1 files and functions, send our function output to the pipeline — good info — and that the results of our functions are consistent. Makes sense, right? If we’re testing that the value should be 5, then it’s not helpful if our code sometimes produces a random 6 (and there’s no test for that). This was actually better stated by Adam, when he wrote, “…for a given input, you get the same output.” His further elaborations were quite good, as well. As someone that uses iBooks and the ePub version, I highlighted a decent amount of the additional explanation.

Moving on, the book discussed that Pester would prefer that input be via parameters. If you’re not there yet, then get there, and stop settling for hard coded values, Read-Host prompts, or a function’s ability to read from the global scope when it can’t find what it wants in its current scope. If you’re not writing in functions — and this is really what this is about — then get there too. I spent a few posts before I started The Pester Book reviews trying to provide reasons why someone would want to do this (outside the community saying you should). It really does make your PowerShell life easier.

The chapter continues on by discussing output (think objects), that actions aren’t output (it makes sense when you read it), and finally, to keep commands as scoped as possible, as they’re easiest to test that way. This can be tough to teach, because people think whole project when they should be thinking task. But seriously, write in functions only, and keep them to a single purpose. Next, we’ll be back with a chapter on Describe Blocks.

This is getting good… I’ve done some Pester authoring previously, but I’ve never been taught it, so I’m looking forward to all those things I’m doing wrong, or didn’t know, because I didn’t give myself a complete training. Well, that’s the purpose of the book. Again, Describe blocks in our next review.

Table of Contents – Pester Concepts

As of this post, I’ve marched head first into Part I of The Pester Book.

It was a short chapter, as it included brief explanations of some Pester Concepts we’ll likely be spending more time with in our future. It explained Tests, as the basic unit of work within Pester. Remember, we’re on our way to learn how to test our PowerShell code with Pester. It also briefly touched on Mocks. This concept allows us to fake dependencies. The example used Get-Content. Instead of needing files from which we’d actually get the content, we can use mocking and have it appear as though we’ve returned the results we want, with the Get-Content cmdlet.

The chapter also included a brief discussion on assertions. It indicated that assertions are a core component of Pester (making a mental note of that). Assertions allow us to compare what should happen, and what does happen, when a specific part of our PowerShell executes.

Next, The Pester Book discussed scaffolding, and TestDrive. Scaffolding is referred to as a starting point for your tests. What it really seemed to be getting at, was the TDD philosophy. That’s the Test-Driven Development philosophy where you write (failing) tests first, then write the code to correct the tests. Without code in which to run your tests against, they’re going to fail, until you write the code that make those tests pass.

TestDrive is awesome. Or at first glance, it sounds like it will be. The TestDrive, drive is a FileSystem drive (like the C:\, D:\, etc.) that becomes available when a Pester test is running. This allows us to have a place to create file system objects while a Pester test is running, without worrying about negatively impacting a true filesystem where we don’t want to make changes.

This is getting good. Back soon.

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.

Table of Contents – My Introduction

Pester. Have you heard about it? I should hope you’ve at least, heard of it.

I know the exact moment I realized that I needed Pester, and decided I would learn it backwards and forwards, once for all. You’ll realize the moment too, if you haven’t already. Before that, providing it hasn’t happened, you need to know a little about what Pester is and what it does, so that when the day comes, you’ll have enough introductory information to now know that it’s a requirement in your life. It happens.

I was working an AWS Windows project that hadn’t yet included Active Directory. In this project and its sub projects, I was essentially creating and configuring Windows workgroup computers. If you consider that the project required a good deal of security and that we didn’t have an Active Directory environment to leverage, you can imagine that I had several settings to edit, in order to secure our machines.

The environments were built using AWS CloudFormation and a couple PowerShell modules that often included several functions. For each sub project, I built a new stack and waited for my instances and other resources to become available. When my instances were completed, I’d jump on them via Remote Desktop and start poking around. Were my users created? Was my SSL certificate for Remote Desktop in place? Were my PowerShell modules in place? Were my software installers in place? Were all the Registry settings applied? I was doing a “quick” and manual visual spot check to make sure my systems were configured correctly. Me, someone that’s dedicated to automation, was doing these things manually. I’d literally remotely connect to an instance, open the PowerShell ConsoleHost, and enter a string of commands that looked like this:

PS > regedit; certlm.msc; compmgmt.msc; ii 'c:\Program Files\WindowsPowerShell\Modules'

The above commands would open up the different graphical utilities that I needed, in order to ensure my automation had run successfully. I could check my registry settings, I could check to see if my certificate was imported, I could check to see if my users were created, and I could check to see if my PowerShell modules were in place. I was doing this manually, even when I knew there was a better way.

I repeatedly thought, I should write a function to do these checks for me. But why write another function? Why not use what’s already been built-in to test my system? Why not improve my project and get more experience with Pester at the same time?

Well, I did. After all those manual checks on my instances, I was just thrilled to see all those green lines produced by Pester, taking milliseconds of time, to remind me of all the time I had already wasted. But I’m okay with it now, as this project presented me an opportunity to really begin to appreciate and utilize Pester. And in that, the time and effort of Adam Bertram.

Follow along as I read Adam’s The Pester Book published on Leanpub.com. I’m not going to teach you Pester per se, but I’m going to write about as though we’re reading the same book together — Adam’s book — and share my thoughts as I do. You ought to get a copy and follow long; we’ll learn this better together. For the foreseeable future, let’s make this blog a weekly review of what we’ve read, so you and I can potentially get more out of our reading. Maybe we’ll do more than a single chapter per week — we’ll see. I’ll be back soon with the first installment; therefore, you should get your copy of The Pester Book today!