Mocking functions in Pester is easy, you just use Mock and you are done. But how do you mock a method on an object?

As described in the v5 readme, the fundamental change in Pester5 is that Pester now runs in two phases: Discovery and Run. During Discovery Pester finds all your tests, groups them together and filters them based on your filters. Then in the Run phase it will actually run them.

Splitting the work into two distinct phases, powers many of the features in this release, and enables many others to be implemented in the future.

For Discovery to work correctly, there are new rules to follow:

Put all your code into It, BeforeAll, BeforeEach, AfterAll or AfterEach. Put no code directly into Describe, Context or on the top of your file, without wrapping it in one of these blocks, unless you have a good reason to do so.

All misplaced code will run during Discovery, and its results won’t be available during Run.

This article offers more guidance and shows examples of what it means.

In Pester 5 you should put your script setup inside of a BeforeAll block. If you are still using this historical approach, then it will no longer work:

BeforeAll {
    $here = Split-Path -Parent $MyInvocation.MyCommand.Path
    $sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".Tests.", ".")
    . "$here\$sut"
}

Describe "Get-Emoji" {
    It "Gets cactus" {
        # your test code
    }
}

Talk from PSDayUK 2019 held Birmingham. In this talk I show the various techniques that can be used to cover your existing code base with tests, including how to mock .NET methods, how to mock .NET types, how to test in module scope and so on.

Talk from PPosh user groun in 2019 held Wroclaw. In this talk I introduce the attendees to testing with Pester, yet another time.

I often see a lot of unnecessary code in WPF demos in PowerShell, so I want to share the most barebone version that still works correctly.

You don’t need to use New-Object System.Xml.XmlNodeReader $xaml, and you don’t need [Windows.Markup.XamlReader]::Load($reader). Just use Parse.

You also don’t need the x and d namespaces (most of the time) so you can remove them as well.

Just make sure that the $xaml variable has type [string], and you can get a working app in just few lines of code.

Add-Type -AssemblyName PresentationFramework

[String]$xaml = @"
<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
    <Grid>
        <Label FontSize="100" Name="Text" /> 
    </Grid>
</Window>
"@

$Window = [Windows.Markup.XamlReader]::Parse($xaml)

$Text = $Window.Content.FindName("Text")
$Text.Content = "👋, from WPF!"

$Window.ShowDialog()

Community enagaement session from PSConfEurope 2019 held in Hannover. I show news in Pester 5 and ask the community if they’d rather want a compatible version or a version that enables a lot of new features.

A session from PSConfEurope 2019 held in Hannover. I show ,ultiple approaches to creating your own custom Pester assertions, and why they are useful.

Few days ago I posted about a tiny module I wrote to skip the entry point function in a script. I got few reactions telling me that there are better ways to organize your scripts, and they were all correct. Putting your code into a module and distributing it that way, or splitting the script into different files and combining them during build are both better than having a single file with everything.

Talk from PSConfEurope 2019 held in Hannover. Shows my wrapper around WPF in PowerShell and how it enables binding to be used in PowerShell which was thought to be impossible.

Testing a self-contained script file with Pester is difficult. I visited this idea few times before, for example here and never reached a solution that I would like, but every time I am getting closer and closer.

Talk from PSConfEurope 2019 held in Hannover. A deep dive into Pester 5 testing framework internals, whith emphasis on scoping and session states, and multiple workarounds that I need to get the desired functionality.

Talk from PSPowerHour 2019 held online. In this talk I show my Import-Script function and how to use it to test self-contained PowerShell scripts.

Talk from PSPowerHour 2018 held online. In this talk I show my Assert module and it’s capabilities, especially Assert-Equivalent which compares objects as a whole.

Talk from PSConfAsia 2018 held in Singapore. Shows an introduction to testing with Pester, with few practical examples.

Talk from PPosh user groun in 2018 held Wroclaw. In this talk I introduce the attendees to testing with Pester.

Talk from PSConfEurope 2018 held in Hannover. Shows how the Pester testing framework works internally and different interesting workarounds that we need to take to provide the functionality.

Talk from PSConfEurope 2018 held in Hannover. Shows common mistakes that test writers make and provides solutions to make your code better.

Seven years ago, on the first day of 2011 the first commit to Pester repository was done by Scott Muc. Little did he know that this minimal implementation of a testing framework, he committed still a bit drunk from the previous evening, will grow into the number one PowerShell testing framework it is today.

Writing a test framework is a lot of fun, and presents some unique challenges to overcome. One of them is testing your assertions. I am writing my own set of assertions for Pester and I also used the same ideas to test some of the Should assertions in Pester.

This weekend I added type filter and -PassThru to Should -Throw. Let’s see how are they useful.

🔥 This feature is not released yet, get pre-release version 4.2.0-alpha3 to use it.

Type filter

Filtering exceptions on type is one of the most basic capabilities of any assertion that deals with exceptions, yet we were missing it till now. But there it is now:

This weekend I added custom failure reasons into Pester. This feature I know and love from Fluent Assertions, so let me show you how I would use it in Pester.

🔥 This feature is not released yet, get pre-release version 4.2.0-alpha3 to use it.

Because parameter

The new feature adds an optional -Because parameter to all Should assertions. The parameter allows you to specify a reason that will be shown when assertion fails, like so:

Few days ago I saw a post about using hieroglyph unicode characters in Haskell to write fully functional haskell code. They shown an example of map function. A function that applies a function to a collection of items. Pretty much how foreach does in PowerShell.

I thought this was fun, and tweeted this:

Talk from PowerShell User Group Singapore. Shows an introduction to testing with Pester, with few practical examples.

I am using PowerShell version 5.0.10018.0 for the examples. This version of PowerShell ships with the WMF February 2015 Preview package that you can download here.

I was asked if there are any resources on testing class based DSC resources. And to be honest I am not sure. We shortly discussed the possibilities on the PS MVP mailing list, but I am still not sure what are the possibilities. So why not discover them while learning something more about the topic.

Luckily there are quite a few great resources on how to actually create a class based DSC resource, and what you need to do that. Some of them are:

Creating a Class based DSC Resource using PowerShell

Class-defined DSC resources in Windows Management Framework 5.0 Preview

Writing a custom DSC resource with PowerShell classes

Lately we are getting some great questions on our Pester issue page, I am reposting soem of my answers as blog posts, because I hope they are worth reading. You can access the original question here.

We test because we need a simple set of boundaries that define a more complicated system. Coming up with simple tests and gradually refining them to define more complex systems is easy for us humans. Definitely easier than defining a complex system in a single swoop.

This week brought quite a few challenges. One of them was a question asked by a friend:

How do I search contents of all the files for given string, without killing the performance of the computer?

This seemed like a simple question to answer: Just lower the priority of the PowerShell process to Idle.

(Get-Process -Id $pid).PriorityClass = 'Idle'

The only problem is, that it does not work.

End-to-end test of simple script

With Pester it is really easy to test a single PowerShell function or a library of them, but what if your script contains some code that runs those functions?

Let’s say we have a script like this one: