PowerShell Modul Development: Pester Tests

This post is also available in Deutsch

Pester tests can be used to ensure a level of quality in PowerShell module development that would otherwise be difficult to achieve manually. There are two important factors to consider. Module and Function Integrity.

Function Integrity

I will explore this point in more detail in a later blog entry. In short, the actual function of the module must be ensured.

A popular example is a function that adds up two numbers. Pester allows you to check if the function really returns 5 when passing 2 + 3.
With a real module this gets more complex quickly.

Module Integrity

All functions in a module and also the module itself should meet certain quality requirements and of course contain valid PowerShell scripts.

During the development of my module AzureSimpleREST I looked around how other developers did it. I found Kevin Marquette’s blog entry “PowerShell: Let’s build the CI/CD pipeline for a new module” and used it as a basis for my module Pester Test.

The following points should be taken into account:

  • Does every PowerShell file contain valid code ?
  • Is the module manifest, the description of the module, valid?
  • Are the exported functions available in the manifest?
  • Are internal functions not exported?
  • Are all aliases defined in the manifest as well?
  • Do the PSScriptAnalyzer Best Practice apply to all scripts?

Not all of these features were included in the original version, so I have greatly extended and modified it. In the following I will explain the individual tests. You can find the complete script in the GitHub Repo.

Pester Tests

Common variables

Some of the following variables are used later on in the tests, e.g. for the names of the tests or path specifications. In addition, it keeps everything dynamic and can be easily  reused.

Module

Every PowerShell script as well as the module manifest and the module file is checked in the section ‘Basic Module Testing’. At first it is only checked if it contains valid PowerShell code and no syntax errors.
Additionally it is checked if the file exists and finally if the module can be imported without errors.

Testing the PowerShell Manifest

In the next section, the manifest file (PSD1) is checked. This includes the following tests

  • Are there critical errors in the manifest file (Test-ModuleManifest)?
  • If the name of the module corresponds to the name in the manifest
  • Is a version declared?
  • If a description has been defined?
  • Is the module file (PSM1) available?
  • If the unique GUID module has not been changed?
  • If no “Format Files” are exported.
  • Are all required modules also specified?

Functions

The functions are checked whether they are specified in the manifest file and are therefore displayed cleanly in the PowerShell Gallery. This is done once using the file names and finally it is checked if the count is correct as well. Thus one does not forget to enter a new function.

For internal functions, that is, functions that are not intended for the end user, the system checks whether the direct call provokes an error.

Aliase

The system also checks whether the aliases are all stored in the manifest and whether they are all exported.

PSScriptAnalyzer

The section for the PSScriptAnalyzer tests is somewhat more extensive. The module ‘PSScriptAnalyzer’ allows the automated checking of scripts in a module for certain best practices. This ensures, for example, that there are no unnecessary spaces in the scripts or that no variables are declared that will not be used later. Currently the script can check 55 different rules, whereby I only use 45.
Anything that corresponds to the severity warning or error will be considered as an error.

In the internet there are many implementations for PSScriptAnalyzer with Pester and each one has its advantages. Personally, it was important to me to also indicate when a file is “clean”, so no rule violations are reported.
In addition, every violation should be clearly visible in the tests and not only the indication of several errors in a function.

To achive that I had to jump through some hoops.

All violations of the defined rules are saved in the $ScriptAnalyzerErrors variable and then written to a PSCustomObject $testCase.
The rule name, script name, error, line number and severity are saved. From these errors Pester now generates dynamic tests which contain the function name, the error and the line number in your name. So it is easy to understand why the test failed and what needs to be corrected.

In addition, all functions with errors are written to the variable $FunctionsWithErrors. This variable is then compared with the complete list of functions and those without errors are stored in the variable $FunctionsWithoutErrors.
This list is then used to generate a series of always successful tests to reward those who did not make any mistakes.