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

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
    }
}

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.

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()

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.

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.

Last week I started a project in F#. In the F# project we are using Giraffe for the backend and we are testing it with Microsoft.AspNetCore.TestHost. This test host allows your ASP.NET Core app to run and be queried, just like it normally would, but with one instance per test and with doing everything in memory. This is great for integration tests, because with a very simple setup you can test your routing, validation, permissions, http return codes, serialization and so on. A lot of stuff that your might otherwise find difficult to test.

Yesterday I had to write a script to do some initial setup on Windows and one of the steps was configuring power settings. I remembered that there were few useful options, but googling them did not help me. Luckily I found the pieces in an old script I wrote. So here are few tips for using powercfg.exe

Regular expressions with capturing groups are super useful for text replacements, and Visual Studio, VS Code, and notepad++ all support them. They can prevent you from doing a lot of boring work, such as:

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:

This always starts of as a joke:

So do you test your tests? When you test your tests, do you test the tests that test your tests?

And people are often surprised that I in fact do test my tests.

With Pester there are two different ways of testing that both look very similar, but are in fact very different.

They say a picture is worth a thousand words. I would say that a great talk is worth ten times more than that. Especially if you are a beginner looking for their way into a new topic. One such topic is functional programming, with its endofunctors, lambda calculus and set theory.

The new version of MS SQL server offers a lot of new cool features. One of them is called system-versioned temporal tables.

As the name suggests, this feature enables versioning for data in table, it does quite simply by creating a second table that holds the historic state of each row, as well as information about the timespan in which the row was valid.

I finished the excellent NoSQL Distilled book yesterday and today I tried to start few mongo sessions and configure them as a cluster. This turned out to be a bit tedious, so I wrote a very rough script for it.

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: