Releases: pester/Pester
5.1.0-beta2
5.1.0-beta1
New features
BeforeDiscovery block
BeforeDiscovery is a semantic block that allows you to group your code together if you need it to run during discovery. It just takes your code and runs it in place. But it gives a nice way of showing that this code is here intentionally, and not just a forgotten piece of code that you did not migrate to Pester v5.
BeforeDiscovery {
$testConfigs = Get-ChildItem -Path $PSScriptRoot/TestConfigs
}
Describe "Platform dependent tests" {
foreach ($config in $testConfigs) {
It "Runs for config $($config.Name)" {
# ...
}
}
}"TestCases" for Describe and Context
-ForEach parameter was added to Describe and Context, and also to It as an alias for -TestCases. Like -TestCases on It you can use this to create one block for each example.
This has been long awaited and this thread has a lot of examples of the usage. #1679
This can also be used with the parameters that you provide directly to the script which was introduced in the previous preview. See example of the usage in the thread. #1679 (comment)
"TestCases" can take any array, not just arrays of hashtables
You can now provide any array to -TestCases / -ForEach, and it will be defined as $_ in your tests. Additionally if your array is an array of hashtables, each key in that hashtable will be expanded to a variable, the same way it already works for -TestCases.
(Just don't use _ as the name of any Key in your hashtable, it won't work well.
Templates expand to all variables and allow dot-notation
Using this syntax <user>, that you know from -TestCases you can now expand value from any variable that is defined in the scope, not just from the provided hashtable. You can use <_> to expand the $_. You can also use dot-notation <user.name>, to navigate into the object. Here an example of the dot-notation in action:
Describe "<animal.name>" -ForEach @(
@{
Animal = @{
Name = "dog"
Sounds = @("woof", "barf")
}
}
@{
Animal = @{
Name = "cat"
Sounds = @("meow", "purr")
}
}
) {
It "<animal.name> goes <_>" -ForEach $Animal.Sounds {
}
}Starting discovery in 1 files.
Discovering in C:\Users\jajares\Desktop\ex.tests.ps1.
Found 4 tests. 48ms
Discovery finished in 61ms.
Running tests from 'C:\Users\jajares\Desktop\ex.tests.ps1'
Describing dog
[+] dog goes woof 10ms (4ms|5ms)
[+] dog goes barf 11ms (2ms|8ms)
Describing cat
[+] cat goes meow 8ms (2ms|7ms)
[+] cat goes purr 8ms (5ms|3ms)
Tests completed in 370ms
Issues Fixed
- Filter excluded tests from NUnit results #1686
- Add -ForEach parameter to Describe, Context, and as an alias to -Test… #1681
- Add BeforeDiscovery semantic block #1680
- Add fallback startline #1678
See full log here
5.0.5-beta1
5.0.4
5.0.4
Issues Fixed
- Add basic elipsis to indicate the array was shortened #1672
- Fix line-based filter for tests with multiline testcases #1664
- Removed unused variable #1663
- Update README.md #1652
- Add support for "-Not" to "Should -Invoke" tests #1665
- Update invoke-pester help to improve #1634 #1648
- Update README.md #1666
- Fix conflicting tests #1658
- Add nugets and publish to nuget and choco #1654
See full log here
5.0.3
- fix formatting for Nunit parameterrized tests #1630
- Add FullNameFilter and PassThru parameters to Simple interface parameter list in README.md #1637
- Fixes #1631 - Updated docs Planets example to work with Pester v5 #1632
- Fix basic scoping of BeforeAll #1636
- (doc): Add Legacy v4 parameter mapping to config object in README.md #1595
See full log here
5.0.2
- Allow splatting to Should again
- Fix
Add-ShouldOperatorerror when importing Pester v5 in session that has v4 - Fix mocking
Test-Path - Make
-OutputPathin the Legacy set non-mandatory
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
-Scriptnot-CodeCoveragetake hashtables, they just take a collection of paths. This is scheduled for 5.1.0. -
The
-Strictparameter and-PesterOptionare ignored. Strict will possibly be fixed in 5.1.0 as well.-PesterOptionis superseded by-Configuration, and you most likely don't need it in your workflow right now. -
The
-Output\-Showparameter takes all the values of v4.- but translates only the most used options to Pester 5 compatible options. Otherwise it uses
Detailedoutput. - It also allows all the Pester 5 output options, to allow you to use
Diagnosticduring migration. - This whole Parameter set is deprecated, and prints a warning.
- but translates only the most used options to Pester 5 compatible options. Otherwise it uses
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
- Tags
- Logging
- Run only what is needed
- Skip on everything
- Collect all Should failures
- Collecting
AfterEachfailures - Normal, Detailed and Diagnostic view
- New result object
- Simple and advanced interface
- PesterPreference
- Scoping of BeforeAll & AfterAll
- Scoping of BeforeEach & AfterEach
- Implicit parameters for TestCases
- Mocking
- VSCode improvements
- Breaking changes
- What is new?
- 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-NullStarting 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 -Throwis 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