Scroll Top
Evotec Services sp. z o.o., ul. Drozdów 6, Mikołów, 43-190, Poland
+48 502 469 760
[email protected]

Converting Pester V4 to Pester V5 basics

Converting Pester V4 to Pester V5 basics
Pester V5
By Przemyslaw Klys PowerShell 28 maja, 2020

Now that Pester V5 is out, I decided that I need to make sure that my Pester tests for all my modules keep on running correctly. Some substantial changes in Pester add new features, changing some things, but that also means all the tests that you have defined most likely will need a small push to get it up and running again on Pester V5. Starting this blog post, I wanted to mention that I am by no means an expert on Pester, but I do use it for some time now for most of my projects.  I am using basic functionality, but even that basic functionality stops working once you upgrade from PesterV4 to PesterV5, so I thought I would save you some time and give you a small overview of how you can quickly fix it. It works for me, but you may have to find your way to fix things.

Pester V5 - Invoke-Pester changes

The first thing that changes is the Invoke-Pester function itself. You no longer have EnableExit, you no longer have Script parameter.

$PSVersionTable.PSVersion

$ModuleName = (Get-ChildItem $PSScriptRoot\*.psd1).BaseName
$RequiredModules = @(
    'PSSharedGoods'
    'Pester'
)
foreach ($_ in $RequiredModules) {
    if ($null -eq (Get-Module -ListAvailable $_)) {
        Write-Warning "$ModuleName - Downloading $_ from PSGallery"
        Install-Module -Name $_ -Repository PSGallery -Force -SkipPublisherCheck
    }
    Import-Module $_ -Force
}
Import-Module $PSScriptRoot\Testimo.psd1 -Force

$result = Invoke-Pester -Script $PSScriptRoot\Tests -Verbose -EnableExit

if ($result.FailedCount -gt 0) {
    throw "$($result.FailedCount) tests failed."
}

If you try to run it without any changes you will get an error:

Invoke-Pester : A parameter cannot be found that matches parameter name 'Script'.

That means we need to change it to supported parameters

Invoke-Pester [[-Path] <string[]>] [-ExcludePath <string[]>] [-TagFilter <string[]>] [-ExcludeTagFilter <string[]>] [-FullNameFilter <string[]>] [-CI] [-Output {Diagnostic | Detailed | Normal | Minimal | None}] [-PassThru]  [<CommonParameters>]

Or

Invoke-Pester [-Configuration <PesterConfiguration>]  [<CommonParameters>]

Knowing what options we have, I can now simply change Path, and the command should mostly behave the same. However, what also changed is now Invoke-Pester runs with minimal output only – meaning it will only show errors if not specified otherwise. And it makes sense – we're mostly interested in errors, right? We don't need 500 tests that passed, but only 42 that didn't. If you still need to see all of it, you need to additionally specify the Output parameter and decide how much information do you need.

$PSVersionTable.PSVersion

$ModuleName = (Get-ChildItem $PSScriptRoot\*.psd1).BaseName
$RequiredModules = @(
    'PSSharedGoods'
    'Pester'
)
foreach ($_ in $RequiredModules) {
    if ($null -eq (Get-Module -ListAvailable $_)) {
        Write-Warning "$ModuleName - Downloading $_ from PSGallery"
        Install-Module -Name $_ -Repository PSGallery -Force -SkipPublisherCheck
    }
    Import-Module $_ -Force
}
Import-Module $PSScriptRoot\Testimo.psd1 -Force

$result = Invoke-Pester -Path $PSScriptRoot\Tests #-Output Detailed

if ($result.FailedCount -gt 0) {
    throw "$($result.FailedCount) tests failed."
}

A simple change and we can see that our command worked, and we saw 420 silently passed and 42 that failed.

Pester V5 - No code in Describe block

The second problem I had with the conversion from PesterV4 to PesterV5 was the information in the documentation that you shouldn't use any code in Describe blocks. That's going to be a problem because I see it as the only way to build tests dynamically. I've reached out to @nohwnd, and he mentioned that it's just good practice, but if I know what I'm doing, it's still allowed. As far as I understand it, the drawback will be – the code in Describe block will run twice. Once during the discovery phase, the second time during real runtime. So far, so good.

As you can see below, I have code defined on lines 2-3 that dynamically test whole Hash for me. But since @nohwnd said it's OK to run code in Describe block when I know what I am doing (and of course I know what I am doing, right?), I run with it.

Describe 'Testimo Sources' {
    $TestimoSources = Get-TestimoSources -Advanced
    foreach ($Source in $TestimoSources) {
        It "Source $($Source.Source) should contain Enable key and be enabled or disabled" {
            $Source.Advanced.Enable | Should -BeIn @($True, $False)
        }
        It "Source $($Source.Source) should contain Source Key" {
            $Source.Advanced.Keys | Should -Contain 'Source'
        }
        It "Source $($Source.Source) should contain 6 in Source Details" {
            $Keys = @(
                'Area'
                'Category'
                'Severity'
                'RiskLevel'
                'Description'
                'Resolution'
                'Resources'
            )
            $Source.Advanced.Source.Details.Keys | Sort-Object | Should -Be ($Keys | Sort-Object)
        }
    }
}

The only problem is, I have all my tests failing – 231 tests. On PesterV4, only some of them failed.

Again a small change was done to how PesterV5 handles things. If you need to pass variables into It block, you need to use a parameter called TestCases. If you don't do that, the variable you have defined outside of It block will not be available in it, and since your tests require it – they will fail.

Describe 'Testimo Sources' {
    $TestimoSources = Get-TestimoSources -Advanced
    foreach ($Source in $TestimoSources) {
        It "Source $($Source.Source) should contain Enable key and be enabled or disabled" -TestCases @{ Source = $Source } {
            $Source.Advanced.Enable | Should -BeIn @($True, $False)
        }
        It "Source $($Source.Source) should contain Source Key" -TestCases @{ Source = $Source } {
            $Source.Advanced.Keys | Should -Contain 'Source'
        }
        It "Source $($Source.Source) should contain 6 in Source Details" -TestCases @{ Source = $Source } {
            $Keys = @(
                'Area'
                'Category'
                'Severity'
                'RiskLevel'
                'Description'
                'Resolution'
                'Resources'
            )
            $Source.Advanced.Source.Details.Keys | Sort-Object | Should -Be ($Keys | Sort-Object)
        }
    }
}

Do you see how each It block now has additional TestCases parameter that's defined as hashtable with mapping outside variable to inside variables? That's how you're supposed to pass data to It blocks now. Now we just need to follow this approach and change all my tests to this new approach. Except, the first test was a small one. I've got plenty of other tests that repeat the same pattern over and over. Here's another one that would require me to change It blocks nine times, and every time I have to do that for a new test I write, I will die a little bit inside.

Describe 'Testimo Configuration for Forest' {
    # Preparations
    $ImportedModule = Import-Module $PSScriptRoot\..\Testimo.psd1 -Force -PassThru
    $TestimoConfiguration = & $ImportedModule {
        $Script:TestimoConfiguration
    }

    foreach ($Key in $TestimoConfiguration['Forest'].Keys) {
        It -Name "Test Source $Key should not be NULL" {
            $TestimoConfiguration['Forest'].$Key | Should -Not -Be $Null
        }
        It -Name "Test Source $Key should contain Enable" {
            $TestimoConfiguration['Forest'].$Key.Keys | Should -Contain 'Enable'
        }
        It -Name "Test Source $Key should contain Source" {
            $TestimoConfiguration['Forest'].$Key.Keys | Should -Contain 'Source'
        }
    }
}

Describe 'Testimo Configuration for Domains' {
    # Preparations
    $ImportedModule = Import-Module $PSScriptRoot\..\Testimo.psd1 -Force -PassThru
    $TestimoConfiguration = & $ImportedModule {
        $Script:TestimoConfiguration
    }

    foreach ($Key in $TestimoConfiguration['Domain'].Keys) {
        It -Name "Test Source $Key should not be NULL" {
            $TestimoConfiguration['Domain'].$Key | Should -Not -Be $Null
        }
        It -Name "Test Source $Key should contain Enable" {
            $TestimoConfiguration['Domain'].$Key.Keys | Should -Contain 'Enable'
        }
        It -Name "Test Source $Key should contain Source" {
            $TestimoConfiguration['Domain'].$Key.Keys | Should -Contain 'Source'
        }
    }
}

Describe 'Testimo Configuration for DomainControllers' {
    # Preparations
    $ImportedModule = Import-Module $PSScriptRoot\..\Testimo.psd1 -Force -PassThru
    $TestimoConfiguration = & $ImportedModule {
        $Script:TestimoConfiguration
    }

    foreach ($Key in $TestimoConfiguration['DomainControllers'].Keys) {
        It -Name "Test Source $Key should not be NULL" {
            $TestimoConfiguration['DomainControllers'].$Key | Should -Not -Be $Null
        }
        It -Name "Test Source $Key should contain Enable" {
            $TestimoConfiguration['DomainControllers'].$Key.Keys | Should -Contain 'Enable'
        }
        It -Name "Test Source $Key should contain Source" {
            $TestimoConfiguration['DomainControllers'].$Key.Keys | Should -Contain 'Source'
        }
    }
}

But fortunately, we can use, not very known, but very useful feature of PowerShell called $PSDefaultParameterValues. It allows you to define default parameters that will be used if no parameter is specified.

$PSDefaultParameterValues = @{
     "It:TestCases" = @{ Key = $Key; TestimoConfiguration = $TestimoConfiguration }
}

Do you see how I tell it that from now on It function parameter called TestCases needs always to be assigned Hash with Keys called Key and TestimoConfiguration and their respective values? You just need to define it once per Describe block (where it makes sense) and voila. Every It block will execute those parameters assigned to it.

Describe 'Testimo Configuration for Forest' {
    # Preparations
    $ImportedModule = Import-Module $PSScriptRoot\..\Testimo.psd1 -Force -PassThru
    $TestimoConfiguration = & $ImportedModule {
        $Script:TestimoConfiguration
    }

    foreach ($Key in $TestimoConfiguration['Forest'].Keys) {
        $PSDefaultParameterValues = @{
            "It:TestCases" = @{ Key = $Key; TestimoConfiguration = $TestimoConfiguration }
        }
        It -Name "Test Source $Key should not be NULL" {
            $TestimoConfiguration['Forest'].$Key | Should -Not -Be $Null
        }
        It -Name "Test Source $Key should contain Enable" {
            $TestimoConfiguration['Forest'].$Key.Keys | Should -Contain 'Enable'
        }
        It -Name "Test Source $Key should contain Source" {
            $TestimoConfiguration['Forest'].$Key.Keys | Should -Contain 'Source'
        }
    }
}

Describe 'Testimo Configuration for Domains' {
    # Preparations
    $ImportedModule = Import-Module $PSScriptRoot\..\Testimo.psd1 -Force -PassThru
    $TestimoConfiguration = & $ImportedModule {
        $Script:TestimoConfiguration
    }

    foreach ($Key in $TestimoConfiguration['Domain'].Keys) {
        $PSDefaultParameterValues = @{
            "It:TestCases" = @{ Key = $Key; TestimoConfiguration = $TestimoConfiguration }
        }
        It -Name "Test Source $Key should not be NULL" {
            $TestimoConfiguration['Domain'].$Key | Should -Not -Be $Null
        }
        It -Name "Test Source $Key should contain Enable" {
            $TestimoConfiguration['Domain'].$Key.Keys | Should -Contain 'Enable'
        }
        It -Name "Test Source $Key should contain Source" {
            $TestimoConfiguration['Domain'].$Key.Keys | Should -Contain 'Source'
        }
    }
}

Describe 'Testimo Configuration for DomainControllers' {
    # Preparations
    $ImportedModule = Import-Module $PSScriptRoot\..\Testimo.psd1 -Force -PassThru
    $TestimoConfiguration = & $ImportedModule {
        $Script:TestimoConfiguration
    }

    foreach ($Key in $TestimoConfiguration['DomainControllers'].Keys) {
        $PSDefaultParameterValues = @{
            "It:TestCases" = @{ Key = $Key; TestimoConfiguration = $TestimoConfiguration }
        }
        It -Name "Test Source $Key should not be NULL" {
            $TestimoConfiguration['DomainControllers'].$Key | Should -Not -Be $Null
        }
        It -Name "Test Source $Key should contain Enable" {
            $TestimoConfiguration['DomainControllers'].$Key.Keys | Should -Contain 'Enable'
        }
        It -Name "Test Source $Key should contain Source" {
            $TestimoConfiguration['DomainControllers'].$Key.Keys | Should -Contain 'Source'
        }
    }
}

And that's it. Now when I rerun my Pester tests, it's beautiful and green, or not so green really, but giving me enough to continue using pester with two small changes.

Przemyslaw Klys / About Author
System Architect with over 14 years of experience in the IT field. Skilled, among others, in Active Directory, Microsoft Exchange and Office 365. Profoundly interested in PowerShell. Software geek.
More posts by Przemyslaw Klys

Posty powiązane

PSBlackListChecker
PSBlackListChecker – Notifications to Microsoft Teams, Slack of Blacklisted IPs
02 lis 2018
Office 365 - Inbox Rules
Office 365 – Find Users Forwarding Emails (PowerShell)
20 paź 2018
Office 365 – msExchHideFromAddressLists does not synchronize with Office 365
24 mar 2020
Restoring (Recovering) PowerShell Scripts from Event Logs
A few days ago, I was asked to take a look at PowerShell Malware. While I don’t know much about malware, my curiosity didn’t let me skip on this occasion, and I was handed over WindowsPowerShell.evtx file. Ok, that’s not what I expected! I wanted PowerShell .ps1 files that I can read and assess? Well, you play with the cards you were dealt with. What I was handed over was PowerShell Event Log. PowerShell writes whatever you execute, and it thinks it is risky, to Windows PowerShell Operation Event Log.
28 sie 2020
Using Win32_UserAccount WMI filter in PowerShell/Group Policies and what to avoid
Some months ago, I created PowerShell Script to create local administrative users on workstations – Create a local user or administrator account in Windows using PowerShell. It’s a bit overcomplicated, but the goal was it should work for Windows 7 and up, and that means supporting PowerShell 2.0. As part of that exercise, I’ve been using Win32_UserAccount WMI based query to find local users and manage them to an extent. While Get-LocalUser exists, it’s not suitable for the PowerShell 2.0 scenario. I also use the same query in GPO for WMI filtering. You can say it’s been a good friend of mine.
02 cze 2020
PowerShell Plus Active Directory Plus Microsoft Graph Equals Love
Report Active Directory Accounts that are Synchronized with Azure AD
I was scrolling X (aka Twitter) today and saw this blog post, „PowerShell: Report On-Premises Active Directory Accounts that are Synchronized with Azure AD Connect” by Kevin Trent. I like reading blog posts as I tend to learn some new things and see how people tend to solve their problems.
07 sie 2023
Preparing Azure App Registrations permissions for Office 365 Service Health
As you may have seen in my other post, there’s a simple, PowerShell way to get Office 365 Health Service data for you to use any way you like it. But before you can use that, you need to register granular permissions on your Office  365 tenant so that that data is provided to you. Here’s a step by step way to do it.
22 kwi 2019
Quickly test multiple proxies with Powershell
Recently we were tasked with testing connectivity with Good For Enterprise servers. Since the environment is highly secure it requires…
0
05 sie 2015
PSWriteHTML-DiagramEventsCalendars
Nested Tabs, Diagram Updates, Diagram Events, Calendar Object and more in PSWriteHTML
One of the new features I’ve worked on was connecting Diagrams with Tables. Someone suggested, and I thought it would be cool to be able to click on the Diagram node and find more details about it in a table next to it. But then I thought it would be even cooler if you could have multiple tables linked to one Diagram. For example, below, I’ve created two tables with Users and Computers and populated Diagram with that data.
13 paź 2019
Using Lansweeper with PowerShell to your advantage
I’m on a tight deadline for one of the chapters for PowerShell Conference Book vol. 2. That means my brain wants me to do a lot of different things but writing that chapter. I’ve decided to write this simple PowerShell command that allows me to use Lansweeper in PowerShell. If you never heard of Lansweeper, it’s a great inventory tool that can scan Windows, Linux, Network, Printers, and other types of assets gathering it all in SQL Database. Usually, you would use their friendly, fast interface to access data it stores because it offers a lot of flexibility, export options, and many many features.
14 lip 2019
PGP Decrypt
Encrypting and decrypting PGP using PowerShell
Some time ago, I decided that having an easy-to-use PGP PowerShell module is a way to kill my boredom. Four months have passed, and I decided to share it with the world, as it may be helpful to some of you.  Today I would like to introduce you to PSPGP – PowerShell module that provides PGP functionality in PowerShell.
12 wrz 2021
PowerShellBlack
Get-ADObject : The server has returned the following error: invalid enumeration context.
In the last weeks, I’m working on a PowerShell module that the main goal is to work on gathering and fixing GPOs. I’ve been testing my module a lot of times on my test environment, and it worked fine till the moment I run it on production, and it started to fail pretty quickly. The difference between my environment and production is 25 GPOs vs. 5000 GPOs. The error I was getting:
15 maj 2020
Difference between GetTempFileName() and GetRandomFileName() that got my ass kicked
Today’s story is about me making assumptions on how things work based on the method’s name. As the blog post says, I want to focus on two similar methods – GetTempFileName() and GetRandomFileName(), when using PowerShell. Still, since those methods are .NET based, it applies to a whole range of other languages – C#, F#, VisualBasic, and all others that I’ve never used.
24 sty 2022
What do we say to health checking Active Directory?
Setting up a new Active Directory is an easy task. You download and install Windows Server, install required roles and in 4 hours or less have a basic Active Directory setup. In an ideal world that would be all and your only task would be to manage users, computers, and groups occasionally creating some Group Policies. Unfortunately, things with Active Directory aren’t as easy as I’ve pictured it. Active Directory is a whole ecosystem and works well ranging from small companies with ten users to 500k users or more (haven’t seen one myself – but so they say!). When you scale Active Directory adding more servers, more domains things tend to get complicated, and while things on top may look like they work correctly, in practice, they may not. That’s why, as an Administrator, you need to manage Active Directory in terms of its Health and Security. Seems easy right? Not quite. While you may think you have done everything, checked everything, there’s always something missing. Unless you have instructions for everything and can guarantee that things stay the same way as you left them forever, it’s a bit more complicated. That’s why Microsoft delivers you tools to the troubleshoot your Active Directory, such as dcdiag, repadmin and some others. They also sell monitoring solutions such as Microsoft SCOM which can help and detect when some things happen in your AD while you were gone. Surely there are some 3rd party companies give you some tools that can help with a lot of that as well. Finally, there is lo of folks within the community creating PowerShell scripts or functions that help with some Health Checks of your Active Directory.
08 wrz 2019
Formatting and minifying resources (HTML, CSS, JavaScript) with PowerShell
When you work with HTML, CSS, and JavaScript, you often meet three versions on how those are stored in files – minified, formatted, somewhere in the middle (usually a total mess). I have all three versions in my PSWriteHTML module. Some are minified 3rd party resources, some are generated by my PowerShell commands (and are a total mess when it comes to formatting), and finally, some are formatted resources by using built-in VSCode features. In whatever form they are, they generally have no impact on how browsers display them. Browsers will read them in any kind and not care for how they look.
11 sie 2019