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.