DOCSEARCHbyAlgolia
Submit Docs

Pester Documentation

website·Indexed 34 days ago

https://pester.dev/

Documentation for Pester, the testing framework for PowerShell. Includes guides on assertions using the Should command, mocking dependencies, test file structure, and configuration via the PesterConfiguration object. Covers versions v5 and v6, including features like TestDrive for file activity, code coverage, and integration with TeamCity.

Tokens
141.3K
Snippets
795
Records
1.1K
Agent score
64%

What's inside Pester

  1. Overview of Pester v4

    v4
    Pester is a Behavior-Driven Development (BDD) based test runner and mocking framework for PowerShell. It allows developers to execute unit tests to validate PowerShell commands, including functions, Cmdlets, Modules, and scripts. Key features include a Testing DSL for isolating and reporting results, a powerful mocking framework to mimic command functionality, and the ability to generate code coverage metrics and test result artifacts for CI/CD pipelines.

  2. Overview of the Pester Planetarium tutorial project

    The Pester tutorial guides users through building and testing a PowerShell module called 'Planetarium' from scratch. The project is designed to cover various testing scenarios, including public functions, private helper functions, data file dependencies, and disk-based report generation.
    Planetarium/
├── Planetarium.psd1
├── Planetarium.psm1
├── Data/
│   └── planets.csv
├── Public/
│   ├── Get-Planet.ps1
│   ├── Get-PlanetDistance.ps1
│   └── Export-PlanetReport.ps1
└── Private/
    ├── ConvertTo-AstronomicalUnit.ps1
    ├── Get-PlanetData.ps1
    └── Test-PlanetName.ps1

  3. Overview of Pester testing framework

    v5
    Pester is a testing and mocking framework for PowerShell used primarily for unit and integration tests, as well as environment and configuration validation. It uses a domain-specific language (DSL) consisting of keywords like Describe, Context, It, Should, and Mock. Pester follows a file naming convention where test files must end in .Tests.ps1 to be discovered and executed. It integrates with Visual Studio Code and CI pipelines, supporting the generation of test result and code coverage artifacts.

  4. Overview of Pester testing framework

    Pester is the standard testing framework for PowerShell, compatible with PowerShell 7.4+ on Windows, Linux, and macOS. It provides a readable, expressive syntax using keywords like Describe, Context, It, and Should to document intent. Key features include:

    • Powerful Mocking: Replace any command with a mock to control return values and assert call counts without needing dependency injection.
    • Built-in Code Coverage: Identify exercised lines of code and export reports in JaCoCo or Cobertura formats.
    • CI/CD Integration: Emit NUnit or JUnit results for platforms like GitHub Actions, Azure Pipelines, and Jenkins.
    • VS Code Support: Integration with the Test Explorer for running, debugging, and scaffolding tests.

  5. Overview of Pester testing framework

    Pester is a testing and mocking framework for PowerShell used primarily for unit and integration tests, as well as environment and deployment validation. It uses a domain-specific language (DSL) consisting of keywords like Describe, Context, It, Should, and Mock. Pester follows a file naming convention where test files must end in .Tests.ps1 to be discovered. It integrates with Visual Studio Code and CI pipelines, and can produce code coverage and test result artifacts.

  6. Overview of Pester Should assertions

    Should is a command used inside It blocks of a Pester test script to provide assertion convenience methods for comparing objects and throwing test failures when expectations are not met.

    Pester v6 supports two styles of assertions:

    1. Classic (v5 style): Uses the Should -Operator syntax (e.g., Should -Be). These are still supported in v6.
    2. Type-aware (v6 style): Uses specialized Should-Operator assertions (e.g., Should-BeEquivalent) with clearer failure messages and input-shape hints.

    To disable the classic v5 syntax in Pester v6, set Should.DisableV5 = $true.

  7. Understand Pester v6 Execution Phases

    Pester runs test files in two distinct phases: Discovery and Run.

    1. Discovery: Pester scans the test files to identify all Describe, Context, and It blocks. It invokes the script blocks of Describe and Context to collect test information, but does not execute the bodies of It, BeforeAll, BeforeEach, AfterAll, or AfterEach blocks.
    2. Run: Pester executes the collected tests and their associated setup/teardown blocks in the correct order, using isolated scopes for each test.

  8. Understand soft assertions in Pester v6

    By default, Pester uses hard assertions: the first failure stops the test immediately. Soft assertions change this behavior so that failing assertions are recorded, but the test continues to run remaining assertions. All collected failures are reported together at the end of the test. This is useful for validating multiple related properties of an object within a single It block.

  9. Use the Should keyword for assertions in Pester v4

    v4
    The Should keyword is used to define assertions inside an It block in Pester v4. It verifies conditions (e.g., comparing objects); if an assertion is not met, the test fails and an exception is thrown. Multiple Should assertions can be used within a single It block, provided each is on a new line. The test passes only if all assertions are met (logical conjunction).

  10. Navigate Pester test files in Visual Studio Code

    The PowerShell extension recognizes Pester blocks (Context, Describe, and It) to provide the following navigation aids:

    • Outline Panel: Displays a hierarchical overview of all Pester blocks in the file.
    • Breadcrumbs & Sticky Scroll: Helps identify the current nesting level of the active code block.
    • Go to Symbol: All Context, Describe, and It blocks are searchable using the standard 'Go to symbol' commands.

  11. Understand Pester v5 Two-Phase Execution

    v5

    Pester v5 uses a two-phase execution model:

    1. Discovery Phase: Pester runs the test script from top to bottom. It executes BeforeDiscovery blocks, Describe blocks, Context blocks, and any script code outside of test-specific blocks. It collects (but does not run) It, BeforeAll, BeforeEach, AfterEach, and AfterAll blocks.
    2. Run Phase: Pester executes the collected BeforeAll, BeforeEach, It, AfterEach, and AfterAll blocks.

    Critical Constraint: Variables defined directly in the script body during the Discovery phase are not available during the Run phase. This means a variable used in a Describe block's name (expanded during Discovery) will be $null inside an It block (executed during Run).

  12. Mock PowerShell command behavior with Pester

    v4
    Pester allows you to mock the behavior of any PowerShell command to fake dependencies or shim data layers. This enables you to control the return values of dependencies and verify that specific commands were called with expected parameters.