5.0.1

The Parameters of Invoke-Pester changed significantly from v4. This release adds a compatibility parameter set.

It should be possible to use all v4 parameters to Invoke-Pester:

Invoke-Pester -Script $testFile -PassThru -Verbose -OutputFile $tr `
    -OutputFormat NUnitXml -CodeCoverage "$tmp/*-*.ps1" `
    -CodeCoverageOutputFile $cc -Show All

The compatibility is not 100%:

• neither -Script not -CodeCoverage take hashtables, they just take a collection of paths. This is scheduled for 5.1.0.

• The -Strict parameter and -PesterOption are ignored. Strict will possibly be fixed in 5.1.0 as well. -PesterOption is superseded by -Configuration, and you most likely don't need it in your workflow right now.

• The -Output \ -Show parameter takes all the values of v4.

  • but translates only the most used options to Pester 5 compatible options. Otherwise it uses Detailed output.
  • It also allows all the Pester 5 output options, to allow you to use Diagnostic during migration.
  • This whole Parameter set is deprecated, and prints a warning.

For more options and the Advanced interface see simple and advanced interface above on how to invoke Pester.

5.0.0

Pester 5.0.0

💵 I am spending most of my weekends making this happen. These release notes for example took multiple days to write and update. Consider sponsoring me or sponsoring Pester, please.

🙋‍ Want to share feedback? Go here, or see more options in Questions?.

• Pester 5.0.0
  • What is new?
    • Discovery & Run
      • Put setup in BeforeAll
      • Review your usage of Skip
      • Review your usage of TestCases
    • Tags
      • Tags on everything
      • Tags use wildcards
    • Logging
    • Run only what is needed
    • Skip on everything
    • Collect all Should failures
    • Collecting AfterEach failures
    • Normal, Detailed and Diagnostic view
    • New result object
    • Simple and advanced interface
      • Simple interface
      • Advanced interface
    • PesterPreference
    • Scoping of BeforeAll & AfterAll
    • Scoping of BeforeEach & AfterEach
    • Implicit parameters for TestCases
    • Mocking
      • Mocks are scoped based on their placement
      • Counting mocks depends on placement
      • Should -Invoke
      • Default parameters for ParameterFilter
      • Mocks can be debugged
      • Internal Mock functions are hidden
      • Avoid putting in InModuleScope around your Describe and It blocks
    • VSCode improvements
      • Use legacy code lens
      • Output verbosity
  • Breaking changes
    • Actual breaking changes
    • Deprecated features
    • Additional issues to be solved in 5.1
• Questions?

What is new?

🔥 Interested only in breaking changes? See breaking changes below.

🕹 want to see a demo? Here is my talk What is new in Pester 5 from #BridgeConf

Pester 5.0.0 is finally here! 🥳 This version recommended to be used for new projects, and is the recommended choice if you just started learning Pester. If you own any project, please give it a try and report back to help me identify bugs.

Discovery & Run

The fundamental change in this release is that Pester now runs in two phases: Discovery and Run. During discovery, it quickly scans your test files and discovers all the Describes, Contexts, Its and other Pester blocks.

This powers many of the features in this release and enables many others to be implemented in the future.

To reap the benefits, there are new rules to follow:

Put all your code into It, BeforeAll, BeforeEach, AfterAll or AfterEach. Put no code directly into Describe, Context or on the top of your file, without wrapping it in one of these blocks, unless you have a good reason to do so.

All misplaced code will run during Discovery, and its results won't be available during Run.

This will allow Pester to control when all of your code is executed, and scope it correctly. This will also keep the amount of code executed during discovery to a minimum. Keeping it fast and responsive. See discovery and script setup article for detailed information.

Put setup in BeforeAll

If your test suite already puts its setups and teardowns into Before* and After*. All you need to do is move the file setup into a BeforeAll block:

BeforeAll {
    # DON'T use $MyInvocation.MyCommand.Path
    . $PSCommandPath.Replace('.Tests.ps1','.ps1')
}

Describe "Get-Cactus" {
    It "Returns 🌵" {
        Get-Cactus | Should -Be '🌵'
    }
}

See migration script for a script that does it for you. Improvements are welcome, e.g. putting code between Describe and It into BeforeAll. See discovery and script setup and importing ps files article for detailed information.

Review your usage of Skip

This also impacts -Skip when you use it with -Skip:$SomeCondition. All the code in the describe block, including your skip conditions and TestCases will be evaluated during Discovery. Prefer static global variables, or code that is cheap to executed. It is not forbidden to put code to figure out the skip outside of BeforeAll, but be aware that it will run on every discovery.

This won't work. BeforeAll runs after Discovery, and so $isSkipped is not defined and ends up being $null -> $false, so the test will run.

Describe "d" {
    BeforeAll {
        function Get-IsSkipped {
            Start-Sleep -Second 1
            $true
        }
        $isSkipped = Get-IsSkipped
    }

    It "i" -Skip:$isSkipped {

    }
}

Changing the code like this will skip the test correctly, but be aware that the code will run every time Discovery is performed on that file. Depending on how you run your tests this might be every time.

function Get-IsSkipped {
    Start-Sleep -Second 1
    $true
}
$isSkipped = Get-IsSkipped

Describe "d" {
    It "i" -Skip:$isSkipped {

    }
}

Consider settings the check statically into a global read-only variable (much like $IsWindows), or caching the response for a while. Are you in this situation? Get in touch via the channels mentioned in Questions?.

Review your usage of TestCases

-TestCases, much like -Skip are evaluated during discovery and saved for later use when the test runs. This means that doing expensive setup for them will be happening every Discovery. On the other hand, you will now find their complete content for each TestCase in Data on the result test object. And also don't need to specify param block.

Tags

Tags on everything

The tag parameter is now available on Describe, Context and It and it is possible to filter tags on any level. You can then use -Tag and -ExcludeTag to run just the tests that you want.

Here you can see an example of a test suite that has acceptance tests and unit tests, and some of the tests are slow, some are flaky, and some only work on Linux. Pester5 makes running all reliable acceptance tests, that can run on Windows is as simple as:

Invoke-Pester $path -Tag "Acceptance" -ExcludeTag "Flaky", "Slow", "LinuxOnly"

Describe "Get-Beer" {

    Context "acceptance tests" -Tag "Acceptance" {

        It "acceptance test 1" -Tag "Slow", "Flaky" {
            1 | Should -Be 1
        }

        It "acceptance test 2" {
            1 | Should -Be 1
        }

        It "acceptance test 3" -Tag "WindowsOnly" {
            1 | Should -Be 1
        }

        It "acceptance test 4" -Tag "Slow" {
            1 | Should -Be 1
        }

        It "acceptance test 5" -Tag "LinuxOnly" {
            1 | Should -Be 1
        }
    }

    Context "unit tests" {

        It "unit test 1" {
            1 | Should -Be 1
        }

        It "unit test 2" -Tag "LinuxOnly" {
            1 | Should -Be 1
        }

    }
}

Starting test discovery in 1 files.
Discovering tests in ...\real-life-tagging-scenarios.tests.ps1.
Found 7 tests. 482ms
Test discovery finished. 800ms

Running tests from '...\real-life-tagging-scenarios.tests.ps1'
Describing Get-Beer
  Context acceptance tests
      [+] acceptance test 2 50ms (29ms|20ms)
      [+] acceptance test 3 42ms (19ms|23ms)
Tests completed in 1.09s
Tests Passed: 2, Failed: 0, Skipped: 0, Total: 7, NotRun: 5

Tags use wildcards

The tags are now also compared as -like wildcards, so you don't have to spell out the whole tag if you can't remember it. This is especially useful when you are running tests locally:

Invoke-Pester $path -ExcludeT "Accept*", "*nuxonly" | Out-Null

Starting test discovery in 1 files.
Discovering tests in ...\real-life-tagging-scenarios.tests.ps1.
Found 7 tests. 59ms
Test discovery finished. 97ms


Running tests from '...\real-life-tagging-scenarios.tests.ps1'
Describing Get-Beer
 Context Unit tests
   [+] unit test 1 15ms (7ms|8ms)
Tests completed in 269ms
Tests Passed: 1, Failed: 0, Skipped: 0, Total: 7, NotRun: 6

Logging

All the major components log extensively.I am using logs as a debugging tool all the time so I make sure the logs are usable and not overly verbose. See if you can figure out why acceptance test 1 is excluded from the run, and why acceptance test 2 runs.

Filter: (Get-Beer) There is 'Flaky, Slow, LinuxO...

5.0.0-rc9 (GA4)

• Fix mock counting for Should -InvokeVerifiable
• Document that Should -Throw is using -like
• Separate files by just one space
• Fix path resolve for CC in 5.1 (missed commit from previous release)

Comparison with rc8: 5.0.0-rc8...5.0.0-rc9

5.0.0-rc8

• Fix mock counting across modules

Comparison with previous pre-release: 5.0.0-rc7...5.0.0-rc8

5.0.0-rc7 (GA2)

Fixes in this release:

• Set-ItResult translates both Pending and Inconclusive to skipped
• Mock splatting is fixed (but mocking Get-PackageSource no longer works)
• TestRegistry and TestDrive teardown correctly when running Pester in Pester
• Fixed resolving paths on PowerShell 5.1

5.0.0-rc6...5.0.0-rc7

5.0.0-rc6

Pester v5 - RC6 (GA)

💵 I am spending most of my weekends making this happen. These release notes for example took multiple days to write and update. Consider sponsoring me or sponsoring Pester, please.

🙋‍ Want to share feedback? Go here, or see more options in Questions?.

• Pester v5 - RC6 (GA)
  • What is new?
    • Discovery & Run
      • Put setup in BeforeAll
      • Review your usage of Skip
      • Review your usage of TestCases
    • Tags
      • Tags on everything
      • Tags use wildcards
    • Logging
    • Run only what is needed
    • Skip on everything
    • Collect all Should failures
    • Collecting AfterEach failures
    • Minimal, Normal and Diagnostic view
    • New result object
    • Simple and advanced interface
      • Simple interface
      • Advanced interface
    • PesterPreference
    • Scoping of BeforeAll & AfterAll
    • Scoping of BeforeEach & AfterEach
    • Implicit parameters for TestCases
    • Mocking
      • Mocks are scoped based on their placement
      • Counting mocks depends on placement
      • Should -Invoke
      • Default parameters for ParameterFilter
      • Mocks can be debugged
      • Internal Mock functions are hidden
      • Avoid putting in InModuleScope around your Describe and It blocks
      • Mocks don't work in top-level BeforeAll
    • VSCode improvements
      • Use legacy code lens
      • Output verbosity
  • Breaking changes
    • Actual breaking changes
    • Deprecated features
    • Additional issues to be solved in 5.1
• Questions?

What is new?

🔥 Interested only in breaking changes? See breaking changes below.

🕹 want to see a demo? Here is my talk What is new in Pester 5 from #BridgeConf

Pester 5 RC6 (GA) is here! 🥳 This version is stable enough to be used for new projects, and is the recommended choice if you just started learning Pester. If you own any project, please give it a try and report back to help me identify any major bugs.

Discovery & Run

The fundamental change in this release is that Pester now runs in two phases: Discovery and Run. During discovery, it quickly scans your test files and discovers all the Describes, Contexts, Its and other Pester blocks.

This powers many of the features in this release and enables many others to be implemented in the future.

To reap the benefits, there are new rules to follow:

Put all your code into It, BeforeAll, BeforeEach, AfterAll or AfterEach. Put no code directly into Describe, Context or on the top of your file, without wrapping it in one of these blocks, unless you have a good reason to do so.

All misplaced code will run during Discovery, and its results won't be available during Run.

This will allow Pester to control when all of your code is executed, and scope it correctly. This will also keep the amount of code executed during discovery to a minimum. Keeping it fast and responsive. See discovery and script setup article for detailed information.

Put setup in BeforeAll

If your test suite already puts its setups and teardowns into Before* and After*. All you need to do is move the file setup into a BeforeAll block:

BeforeAll {
    # DON'T use $MyInvocation.MyCommand.Path
    . $PSCommandPath.Replace('.Tests.ps1','.ps1')
}

Describe "Get-Cactus" {
    It "Returns 🌵" {
        Get-Cactus | Should -Be '🌵'
    }
}

See migration script for a script that does it for you. Improvements are welcome, e.g. putting code between Describe and It into BeforeAll. See discovery and script setup and importing ps files article for detailed information.

Review your usage of Skip

This also impacts -Skip when you use it with -Skip:$SomeCondition. All the code in the describe block, including your skip conditions and TestCases will be evaluated during Discovery. Prefer static global variables, or code that is cheap to executed. It is not forbidden to put code to figure out the skip outside of BeforeAll, but be aware that it will run on every discovery.

This won't work. BeforeAll runs after Discovery, and so $isSkipped is not defined and ends up being $null -> $false, so the test will run.

Describe "d" {
    BeforeAll {
        function Get-IsSkipped {
            Start-Sleep -Second 1
            $true
        }
        $isSkipped = Get-IsSkipped
    }

    It "i" -Skip:$isSkipped {

    }
}

Changing the code like this will skip the test correctly, but be aware that the code will run every time Discovery is performed on that file. Depending on how you run your tests this might be every time.

function Get-IsSkipped {
    Start-Sleep -Second 1
    $true
}
$isSkipped = Get-IsSkipped

Describe "d" {
    It "i" -Skip:$isSkipped {

    }
}

Consider settings the check statically into a global read-only variable (much like $IsWindows), or caching the response for a while. Are you in this situation? Get in touch via the channels mentioned in Questions?.

Review your usage of TestCases

-TestCases, much like -Skip are evaluated during discovery and saved for later use when the test runs. This means that doing expensive setup for them will be happening every Discovery. On the other hand, you will now find their complete content for each TestCase in Data on the result test object. And also don't need to specify param block.

Tags

Tags on everything

The tag parameter is now available on Describe, Context and It and it is possible to filter tags on any level. You can then use -Tag and -ExcludeTag to run just the tests that you want.

Here you can see an example of a test suite that has acceptance tests and unit tests, and some of the tests are slow, some are flaky, and some only work on Linux. Pester5 makes running all reliable acceptance tests, that can run on Windows is as simple as:

Invoke-Pester $path -Tag "Acceptance" -ExcludeTag "Flaky", "Slow", "LinuxOnly"

Describe "Get-Beer" {

    Context "acceptance tests" -Tag "Acceptance" {

        It "acceptance test 1" -Tag "Slow", "Flaky" {
            1 | Should -Be 1
        }

        It "acceptance test 2" {
            1 | Should -Be 1
        }

        It "acceptance test 3" -Tag "WindowsOnly" {
            1 | Should -Be 1
        }

        It "acceptance test 4" -Tag "Slow" {
            1 | Should -Be 1
        }

        It "acceptance test 5" -Tag "LinuxOnly" {
            1 | Should -Be 1
        }
    }

    Context "unit tests" {

        It "unit test 1" {
            1 | Should -Be 1
        }

        It "unit test 2" -Tag "LinuxOnly" {
            1 | Should -Be 1
        }

    }
}

Starting test discovery in 1 files.
Discovering tests in ...\real-life-tagging-scenarios.tests.ps1.
Found 7 tests. 482ms
Test discovery finished. 800ms

Running tests from '...\real-life-tagging-scenarios.tests.ps1'
Describing Get-Beer
  Context acceptance tests
      [+] acceptance test 2 50ms (29ms|20ms)
      [+] acceptance test 3 42ms (19ms|23ms)
Tests completed in 1.09s
Tests Passed: 2, Failed: 0, Skipped: 0, Total: 7, NotRun: 5

Tags use wildcards

The tags are now also compared as -like wildcards, so you don't have to spell out the whole tag if you can't remember it. This is especially useful when you are running tests locally:

Invoke-Pester $path -ExcludeT "Accept*", "*nuxonly" | Out-Null

Starting test discovery in 1 files.
Discovering tests in ...\real-life-tagging-scenarios.tests.ps1.
Found 7 tests. 59ms
Test discovery finished. 97ms


Running tests from '...\real-life-tagging-scenarios.tests.ps1'
Describing Get-Beer
 Context Unit tests
   [+] unit test 1 15ms (7ms|8ms)
Tests completed in 269ms
Tests Passed: 1, Failed: 0, Skipped: 0, Total: 7, NotRun: 6

Logging

All the major components log extensively.I am using logs as a debugging tool all the time so I make sure the logs are usable and not overly verbose. See if you can figure out why `...

5.0.0-rc5

• Add debugging mocks
• Pre-build the binaries
• Optimize runtime
• Move all builds to AzureDevOps

Release notes in this huge readme: https://github.com/pester/Pester/blob/v5.0/README.md

List of changes 5.0.0-rc4...5.0.0-rc5

5.0.0-rc4

Merges module into a single file, taking the load time down to <1s.

Release notes in this huge readme: https://github.com/pester/Pester/blob/v5.0/README.md

List of changes 5.0.0-rc3...5.0.0-rc4

5.0.0-rc3

Adds -PassThru and -FullNameParameter, improves speed of discovery, defining and asserting mocks and should.

Release notes in this huge readme: https://github.com/pester/Pester/blob/v5.0/README.md

List of changes 5.0.0-rc1...5.0.0-rc3

5.0.0-rc2

Broken release. Do not use.