I'm finding v5 incredibly confusing and frustrating...am I missing something basic?

[OranguTech]

I've got a handful of inherited v3 tests, a smattering in v4 I've written, but I'm finding v5 just incredibly confusing/frustrating to get started.

This is the 2nd or 3rd time I've tried to get some tests going in v5, and just to be able to pass parameters to invoke-pester I first have to create a "container" object? To change invocation options I have to create and modify a configuration object, and then I can't mix that with other commandline switches - do I have that right?

Just to run a basic "hello world" dead-simple test (without reverting to the deprecated v4 parameters) I have to execute N setup commands/ write a wrapper script?

[fflaten]

Thanks for trying out Pester.

Running Pester tests can be as simple as Invoke-Pester and optionally a few simple parameters to filter tests or adjust output level.

If you need more advanced features you quickly need a configuration object. There's been a few major changes and lots of new features since v3. Parameters on a single command didn't really scale.

If you haven't already, please check out our quick start guide.

... just to be able to pass parameters to invoke-pester I first have to create a "container" object?

Yes. Providing external data through parameters requires creating a container. See https://pester.dev/docs/usage/data-driven-tests#providing-external-data-to-tests

If possible, consider using a BeforeDiscovery block in your test-file to gather the data instead of providing it through parameters. See https://pester.dev/docs/usage/data-driven-tests#beforediscovery

[nohwnd]

If you have some suggestions how to make it less complicated to get started please propose them. Bare Invoke-Pester works, and anything more advanced is done via the configuration object, which itself is browsable and IMHO beats providing hashtables without schema, or or gazillion of parameters like -CoverageOutputFormat.

But let's discuss. 🙂

[OranguTech]

Thanks everyone for responding - and yes, I had every every link you shared already open in at least one tab. :P I'm sure the functionality is there, I think there's a gulf in between the "getting started" examples and the rest of the documentation for onboarding people. I suspect it's also just designed in a way that makes sense for a certain type of very smart folks, but it doesn't match any of my current mental models. Perhaps also there are examples I have not yet found. (I have found the "Teach yourself Pester" video and repo)

I'm sure the fact I'm using it for env tests over remote PS as ersatz Configuration Management doesn't help. :)

FWIW I do have it working now in a simple form, for the moment I'm bypassing the parameter issue by setting a global variable and having the param default to that.

Gotcha's so far: (I will probably update this as I progress)

• The aforementioned parameter passing.

• The aforementioned config piece.

• Write-Output doesn't appear to work. (Where is that stream going?), have to use write-host for verifying "is this chunk of code firing when I expect".

• Needing to add passthru in order to assign test output to a var. (Is there some other better, more straightforward, way to record test results?)

• I had to stumble upon the assertion reference to even know there are assertions other than -Be. (!)

• I'm still not 100% clear on the difference (or rather, the implications) of BeforeAll vs BeforeDiscovery.

(Heck, under "Discovery and Run" it says BeforeDiscovery { # <- this will run during Discovery - So which is it, before or during?)

[fflaten]

We appreciate the feedback. I've long wanted to add a follow-along tutorial for testing a reference module from start to finish. One day 🤞

Write-Output doesn't appear to work. (Where is that stream going?), have to use write-host for verifying "is this chunk of code firing when I expect"

The output stream is captured so any objects don't break the test report. You can still access it through the result object by using -PassThru or enabling Run.PassThru setting in PesterConfiguration. Example:

$run = Invoke-Pester -PassThru -Output Detailed -Container (New-PesterContainer -ScriptBlock {
  Describe 'demo' {
    It 'i' {
      $someVar= Write-Output "Some output"
      $someVar | Should -BeLike 'Some*'
      $someVar | Should -BeLike '*output'
      # capture it as well
      $someVar
    }
  }
})

$run.Tests[0].StandardOutput
# Output
Some output

Remember that you can have multiple assertions in a test. Then you'd be able to check what you need and get a proper error when it doesn't.

Needing to add passthru in order to assign test output to a var. (Is there some other better, more straightforward, way to record test results?

PassThru is the way for post-processing the test-result or generate custom reports using PowerShell. For CI reporting etc, see XML-reports

I had to stumble upon the assertion reference to even know there are assertions other than -Be. (!)

Any thoughts on where you'd expect to discover it? We already have tab-completion Should -<tab> and online help showing all of them. Pester v6 will include a new set of assertions with individual Should-* functions that'll show up in Get-Command.

I'm still not 100% clear on the difference (or rather, the implications) of BeforeAll vs BeforeDiscovery.

(Heck, under "Discovery and Run" it says BeforeDiscovery { # <- this will run during Discovery - So which is it, before or during?)

Understandable, as it is the most complex change from v3/4 -> v5+. The comment is trying to say "executed during the Discovery-phase". The process is documented here as you've seen. As you already have v3/v4 tests, reading this might help: https://pester.dev/docs/usage/data-driven-tests#migrating-from-pester-v4