New to pester 5, Getting started, and design decisions behind v5?

[OranguTech]

Thanks everyone that puts work into Pester, we use it at $OfficialJob for Infrastructure tests (For $Reasons), mostly ver 3, a bit of 4 even in an Azure Devops Pipeline.

I'm finding ver 5 very difficult to wrap my head around. Most of the details I think are hidden away in the documentation, but are more hinted at rather than explicit:

• 1 - What's the reason behind having a discovery pass? I've re-read the "Discovery and Run" and "Data Driven Tests" entries multiple times, and I'm still not understanding when vars/values are in-scope and when not, or why.
• 2 - What, exactly, is a container in the Pester context, and why would I want to use it? How is that different than a Pester "configuration"? They seem mutually exclusive?
• 3 - I don't understand https://pester.dev/docs/usage/Configuration#pesterpreference, $PesterPreference just seems to be a Pester Config. How is $PesterPreference = [PesterConfiguration]::Default different than $PesterConfig = New-Pesterconfig? .Gettype() shows they are the same.
• 4 - Are containers (and/or configs) required be able to pass parameters into tests? If so, why? As it is, it looks like I'd have to set up every collection of tests with its own "Take a parameter, create a container with that param and kick off the tests" master script.

Thanks for any pointers, etc.

[nohwnd]

Hello, thanks for the questions:

1. What's the reason behind having a discovery pass?

There are multiple features that discovery enables. Most importantly it's being able to run single test, or a group of tests in a file or multiple files without having to run all setups around it. This is not very useful for CI runs, but is valuable for interactive runs, for example in VSCode where the Test UI can first do Discovery only, figure out what tests are there without actually running them and you can then choose what to run.

I agree data driven tests are more complicated than before. The scopes are not very complicated though. The scriptblocks that you provide to It, BeforeAll, BeforeEach, AfterEach and AfterAll are all run during Run. Everything else, that is: code in the script directly, code in the body of Describe, code in the body of Context, code in BeforeDiscovery and also parameters. Most notably -Foreach (-TestCases) are also evaluated during Discovery.

2. What, exactly, is a container in the Pester context, and why would I want to use it?

Container in Pester is just this:

@{
    Type = "File"
    Item = "C:\tests\My.Tests.ps1"
    Data = @{
        Name = "Jakub"
    }
}

A path to a file (or a scriptblock) that has test code in it, and a hashtable that has data for those tests. What might confuse you is that you can provide multiple paths, and multiple hashtables to New-PesterContainer. This is just for convenience, when this object is received by Pester it will "multiply" the data, to end up with multiple objects each having only 1 path and only 1 hashtable of data:

# gives the same object as shown above
New-PesterContainer -Path "C:\tests\My.Tests.ps1" -Data @{ Name = "Jakub" }

# gives two objects that look like the one shown above, but each gets it's own data
New-PesterContainer -Path "C:\tests\My.Tests.ps1" -Data @{ Name = "Jakub" }, @{ Name = "Jaap" }

# gives two objects that look like the one shown above, each gets one path, and the same data
New-PesterContainer -Path "C:\tests\My.Tests.ps1", "C:\tests\My2.Tests.ps1" -Data @{ Name = "Jakub" }

You would want to use it when you provide data to your tests, especially when you provide the same set of tests to multiple files, or all files in a given directory. You can also use it to provide a scriptblock if you want a self-contained example that just runs (we use this extensively in testing Pester).

Also you are already using container every time you use Pester. When you provide -Path, it is internally translated to a container with no data.

How is that different than a Pester "configuration"?

Configuration is a different thing all together. Configuration contains everything that can be configured in Pester, and is internally used everywhere. Configuration, takes Container in the Run section. And it also takes Path, and ScriptBlock, all three are internally converted to Container.

3. $PesterPreference is similar to $ErrorActionPreference. Pester knows that it should look for variable named PesterPreference and if it has configuration in it, it should be used as the default configuration. You could for example set this to always show you Detailed output, if you like that more than the Normal that is the default in Pester:

$PesterPreference = New-PesterConfiguration -Hashtable @{ Output = @{ Verbosity = "Detailed" } }

4. Are containers (and/or configs) required be able to pass parameters into tests? If so, why?

Containers are required to pass data to tests, but you can do everything inline if you want, for example this is how you'd run all test files with the given data:

Invoke-Pester -Container (New-PesterContainer -Path . -Data @{ Name = "Jakub" })

There could also be a convenience syntax Invoke-Pester -Path . -Data @{ Name = "Jakub" } but it is not there (yet?), which would do the same thing.

[OranguTech]

Thank you very much for a detailed reply! Once I have more hands on experience, if I can remember I'll try to add clarifying info the to docs.