Your Code Sucks. Sincerely, Pester

One of the many benefits of testing is that it forces best practices. Testing forces you to write more modular, testable code. Here’s a great example:

I was writing a test for a function that called another function that returned a non-terminating error if something could not be found. I needed to account for this. Here’s the gist of the function:

When Get-OtherThing coudln’t find $Name it returned a non-terminating error that had the string “was not found” inside of it. I needed my Teat-Thing function to just return $true or $false. To do this, I had to capture the non-terminating error that was returned from Get-OtherThing. The only way to do this (I thought) was to silence the error and capture it using ErrorAction and ErrorVariable.

This worked fine until I began to write a unit test for it. I couldn’t figure out how to properly mock the ErrorVariable. After some thinking about it, I came up with a better solution. Why not just set $ErrorActionPreference to Stop which would make all non-terminating errors to be terminating errors. I could then use a try/catch block. The function then turned into this:

Now that my function was using try/catch I could now mock Get-OtherThing to throw exceptions rather than figuring out how to account for non-terminating errors!

To learn more about writing tests for PowerShell and how to use Pester, be sure to check out the #Pester Book by Don Jones and myself!

Adam Bertram

Chief Automator at Adam the Automator, LLC
Adam Bertram is an independent consultant, technical writer, trainer and presenter. Adam specializes in consulting and evangelizing all things IT automation mainly focused around Windows PowerShell. Adam is a Microsoft Windows PowerShell MVP, 2015 PowerShell hero and has numerous Microsoft IT pro certifications. He authors IT pro course content for Pluralsight, is a regular contributor to numerous print and online publications and presents at various user groups and conferences.You can find Adam here on the blog or on Twitter at @adbertram.


  • I use MS-DOS batch files to automate operations processes.
    Is there a way to port legacy MS-DOS batch programs to powershell?
    Is there any benefit to doing a conversion from MS-DOS batch programs to powershell if
    the target objective is the same?
    I use MS-DOS batch programs under Windows 95 (x86) – Windows 10 (x64) using command prompt(s).

    • There’s no way to directly to do it. You’d have to just manually read what the batch files are doing and then write PowerShell scripts to do the same thing. If the batch files are working as you need them to AND you don’t need to change them then I’d just leave them. Just starting writing PowerShell from now on. However, if you are finding yourself needing to go in and change them occasionally or they’re breaking then it’s time to get those over to PowerShell.

      Ditch the batch files. You have a MUCH more powerful way of automating things with PowerShell.

Leave a Reply