PowerShell & Scripting

Pester

Overview

Pester ist das verbreitete Test- und Mocking-Framework für PowerShell. Du schreibst Tests in Dateien mit der Endung .Tests.ps1, gliederst sie mit Describe, Context und It und prüfst Ergebnisse mit Should-Assertions. Neben Unit-Tests eignet sich Pester für Integrationstests und für Infrastrukturprüfungen, etwa ob Dienste laufen oder Ports erreichbar sind.

Wichtige Korrektur: Windows 10, Windows 11 und Windows Server ab 2016 liefern Pester 3.4.0 mit. Diese Version ist stark veraltet, von Microsoft signiert und lässt sich nicht per Update-Module aktualisieren. Aktuelle Versionen installierst Du parallel. Aktuell ist Pester 6 (zuletzt 6.2.0), die Wartungslinie 5 erhält noch Patches (5.9.1).

Pester 6 setzt Windows PowerShell 5.1 oder PowerShell 7.4 und neuer voraus. Es bringt neue Should-*-Assertions wie Should-Be, die klassische Syntax Should -Be funktioniert weiter. Assert-MockCalled und Assert-VerifiableMock sind entfernt und durch Should -Invoke und Should -InvokeVerifiable ersetzt.

How it works

Aufbau und Ablauf eines Tests:

  1. Installation der aktuellen Version neben 3.4.0: Install-Module -Name Pester -Force -SkipPublisherCheck. -Force erlaubt die Parallelinstallation, -SkipPublisherCheck akzeptiert das andere Signaturzertifikat. Spätere Updates klappen mit Update-Module.
  2. In der Testdatei lädt ein BeforeAll-Block den zu testenden Code, meist per Dot-Sourcing über $PSScriptRoot.
  3. Describe gruppiert die Tests einer Funktion, Context unterteilt nach Szenario, It enthält den einzelnen Test.
  4. Mock ersetzt Befehle durch Platzhalter, Should -Invoke prüft, ob und wie oft sie aufgerufen wurden.
  5. Invoke-Pester führt die Tests aus, -Output Detailed zeigt jedes Ergebnis.

In Pester 6 wird jede Datei vollständig erkannt und ausgeführt, bevor die nächste startet. Codeabdeckung basiert standardmäßig auf dem Profiler und kann im Cobertura-Format ausgegeben werden. Ein experimenteller paralleler Runner steht unter PowerShell 7 bereit.

Benefits

  • Sicherere Änderungen: Tests zeigen sofort, ob eine Anpassung bestehende Funktionen bricht
  • Mocking: Externe Systeme wie AD oder Exchange lassen sich simulieren, Tests laufen deshalb ohne Produktivzugriff
  • CI/CD-tauglich: Ergebnisse und Codeabdeckung lassen sich in Azure DevOps oder GitHub Actions auswerten
  • Infrastrukturprüfung: Dieselbe Syntax prüft nach Wartungen, ob Server im erwarteten Zustand sind

Practical example

Ein IT-Dienstleister mit 35 Mitarbeitenden pflegt ein internes Modul für Kundenonboardings. Nach einem Update fiel eine Funktion zur Lizenzzuweisung aus, was erst beim Kunden auffiel. Das Team schreibt Pester-Tests mit Mocks für die Graph-Cmdlets und lässt sie bei jedem Commit in der Pipeline laufen. Fehler wie dieser fallen seitdem vor der Auslieferung auf.

Things to keep in mind

  • Nicht mit der vorinstallierten Version 3.4.0 arbeiten: Syntax und Funktionen weichen stark ab, aktuelle Version parallel installieren
  • Vor dem Wechsel auf Pester 6 den Migrationsleitfaden lesen, weil Assert-MockCalled, -Focus und der Status Pending entfallen sind
  • Tests gegen Produktivsysteme vermeiden und externe Aufrufe mocken
  • In Pipelines die Pester-Version festschreiben, damit Builds reproduzierbar bleiben

Licensing & availability

Pester ist kostenlos und Open Source und wird von der Community gepflegt. Windows liefert nur die veraltete Version 3.4.0 mit, aktuelle Versionen kommen aus der PowerShell Gallery. Pester 6 benötigt Windows PowerShell 5.1 oder PowerShell 7.4 und neuer. Stand: Oktober 2026.

Conclusion

Pester ist das Werkzeug, um PowerShell-Code wie Software zu behandeln. Installiere die aktuelle Version parallel zur vorinstallierten 3.4.0 und binde die Tests in Deine Pipeline ein.

Further reading

Related articles