Skip to content
5 min read

Installing Pester (and Untangling v3/4 vs v5)

  • PowerShell
  • Pester
  • Installation
  • PSGallery
  • Beginners

The most common first-day failure with Pester isn't a typo. It's that your perfectly correct Should -Be example errors out because Windows shipped Pester 3.4 years ago and it's quietly shadowing the modern version you think you installed. This post gets you to a clean Pester 5.x setup and explains exactly why this happens, so it never bites you twice.

What you'll learn

  • How to check which Pester version(s) you actually have
  • Why Windows ships an old Pester 3.4 and how it shadows v5
  • How to install or update Pester from the PowerShell Gallery, correctly
  • How to import a specific version and verify it loaded
  • The differences between Windows PowerShell 5.1 and PowerShell 7

Step 1: See what you already have

Before installing anything, look at what is on the machine:

Get-Module -ListAvailable Pester | Select-Object Name, Version, Path

On a typical Windows machine you'll often see two entries: a 3.4.0 under C:\Program Files\WindowsPowerShell\Modules (built-in), and possibly a 5.x if someone installed it. Seeing 3.4.0 is normal. The problem is which one PowerShell picks when you just type Import-Module Pester.

Step 2: Why the old 3.4 is there (and why it shadows v5)

Windows ships Pester 3.4 as a system module so that built-in tooling has something to rely on. The catch is that this built-in copy lives in a protected, high-priority module path. When you run a bare Import-Module Pester, PowerShell may load the old 3.4 before your newer 5.x, even after you install v5.

Why does this matter so much? Pester 5 is a near-total rewrite with different syntax. In v3/v4 you wrote Should Be 4 (space-separated). In v5 it is Should -Be 4 (a real parameter). Run v5 syntax under v3 and you get confusing errors that look like your mistake but are really a version mismatch.

Step 3: Install or update from the PowerShell Gallery

Install the current Pester from the PSGallery. The two switches matter:

Install-Module Pester -Force -SkipPublisherCheck -Scope CurrentUser
  • -Force lets the install proceed even though an older Pester (the built-in 3.4) is already present.
  • -SkipPublisherCheck is required because the built-in 3.4 was signed by Microsoft and the Gallery release is signed differently; without this switch the install is blocked with a publisher-mismatch error.
  • -Scope CurrentUser installs into your user profile, which doesn't require an elevated admin prompt.

If you prefer a system-wide install, drop -Scope CurrentUser and run from an elevated session.

Step 4: Import a specific version and verify

Do not trust a bare import. Ask for v5 explicitly:

# Force any old copy out of this session first, then import 5.x
Remove-Module Pester -ErrorAction SilentlyContinue
Import-Module Pester -MinimumVersion 5.0

Get-Module Pester | Select-Object Name, Version

That last line should report a Version of 5.x (for example, 5.5.0). If it still shows 3.4.0, the old module won the load order, restart your session and import with -MinimumVersion 5.0 again. You can also pin an exact build with -RequiredVersion 5.5.0 when you need reproducibility.

Step 5: PowerShell 5.1 vs PowerShell 7

Two PowerShells exist, and Pester works on both:

  • Windows PowerShell 5.1 is the one preinstalled on Windows. This is where the shadowing 3.4 lives, so the steps above matter most here.
  • PowerShell 7 (the cross-platform, open-source edition) does not ship Pester 3.4. A fresh PowerShell 7 install starts clean, you just Install-Module Pester and you are done.

For learning, either is fine. If you have PowerShell 7 available, you will hit fewer version surprises.

Try it yourself

Your goal: reach a clean Get-Module Pester showing 5.x loaded.

# 1. What do you have?
Get-Module -ListAvailable Pester | Select-Object Version, Path

# 2. Install the modern release
Install-Module Pester -Force -SkipPublisherCheck -Scope CurrentUser

# 3. Load 5.x explicitly in a fresh session
Remove-Module Pester -ErrorAction SilentlyContinue
Import-Module Pester -MinimumVersion 5.0

# 4. Prove it
Get-Module Pester | Select-Object Name, Version

When step 4 prints a 5.x version, you are ready for the rest of the series. Tuck this snippet away, you will run it on every new machine.

Common mistakes

Update-Module Pester does nothing. The built-in 3.4 sits in a protected system path that Update-Module cannot touch, so it silently no-ops. Use Install-Module ... -Force -SkipPublisherCheck instead, which installs a fresh 5.x alongside it.

Forgetting -SkipPublisherCheck. Without it, the install fails with a publisher-mismatch error because the old built-in copy is signed differently from the Gallery release. This is the single most common install blocker.

Mixing v3 and v5 syntax in one session. If an old Pester is loaded, v5 examples like Should -Be fail in baffling ways. Always Remove-Module Pester and re-import with -MinimumVersion 5.0 when in doubt, then check Get-Module Pester.

Recap

Windows ships Pester 3.4 in a protected path, and it can shadow the modern version, which is why Update-Module quietly fails and bare imports load the wrong release. Install from the PSGallery with -Force -SkipPublisherCheck, then import explicitly with -MinimumVersion 5.0 and verify with Get-Module Pester. PowerShell 7 sidesteps most of this by not shipping the old version at all.

Next up: Part 3 — Your First Test: Describe, It, and Should, where you finally write a real (and very small) Pester test, watch it pass, then break it on purpose to see it turn red.