OLD: This PR is still a draft and not yet ready to be merged. There's one test failure that I don't understand. If a maintainer knows the right change here, please feel free to edit.

| - Running in PSHost without UI 
[n] - Executes successfully without errors -> Expected not $null but got $null. 
  at Verify-NotNull, /Users/runner/work/1/s/tst/axiom/Verify-NotNull.ps1:8 
  at <ScriptBlock>, /Users/runner/work/1/s/tst/Pester.RSpec.InNewProcess.ts.ps1:387 
  at t, /Users/runner/work/1/s/tst/p.psm1:110 
  at <ScriptBlock>, /Users/runner/work/1/s/tst/Pester.RSpec.InNewProcess.ts.ps1:374 
  at b, /Users/runner/work/1/s/tst/p.psm1:80 
  at <ScriptBlock>, /Users/runner/work/1/s/tst/Pester.RSpec.InNewProcess.ts.ps1:372 
  at i, /Users/runner/work/1/s/tst/p.psm1:45 
  at <ScriptBlock>, /Users/runner/work/1/s/tst/Pester.RSpec.InNewProcess.ts.ps1:19 
  at <ScriptBlock>, /Users/runner/work/1/s/test.ps1:93 
  at <ScriptBlock>, /Users/runner/work/1/s/test.ps1:86 
  at <ScriptBlock>, /Users/runner/work/_temp/66f25778-d7a2-4923-949a-c5761f8e13bd.ps1:3 
  at <ScriptBlock>, <No file>:1 

EDIT: Found the answer; see below.

I figured out why that one test was failed and made an edit to get it to pass. I think the PR is ready to now.

Thanks for the PR, can you add more information about the fix, and add a specific test for it? The edit in the current test looks little suspicious, can you explain why it needs to change like this?

also putting the Fixes #number directly into the PR description is more helpful, because it will link the PR to the issue, and will close automatically, unlike if you put it in the title 🙂

also putting the Fixes #number directly into the PR description is more helpful, because it will link the PR to the issue, and will close automatically, unlike if you put it in the title 🙂

Oh, I thought it worked either way, based on the docs and previous experience:
https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue

For example, in this case, I think it still linked the issue automatically (see above). Let me know if you want me to change it anyway though.

Thanks for the PR, can you add more information about the fix, and add a specific test for it?

sure - done

The edit in the current test looks little suspicious, can you explain why it needs to change like this?

Sure - here's what this test output would look like for a file:

Starting discovery in 1 files.
Discovery found 1 tests in 865ms.
Running tests.
[+] path\to\some\Tests.ps1 4.22s (980ms|2.52s)
Tests completed in 4.33s
Tests Passed: 1, Failed: 0, Skipped: 0, Inconclusive: 0, NotRun: 0

but here's what it currently looks like for a ScriptBlock:

Starting discovery in 1 files.
Discovery found 1 tests in 83ms.
Running tests.
[+]  Describe 'd' { It 'i' { 1 | Should -Be 1 } }  145ms (6ms|58ms)
Tests completed in 150ms
Tests Passed: 1, Failed: 0, Skipped: 0, Inconclusive: 0, NotRun: 0

i.e. it includes the entire code for the ScriptBlock rather than the ScriptBlock's formatted "name". It probably gets really messy if the script block is long.

The updated code instead shows it more like a normal file:

Starting discovery in 1 files.
Discovery found 1 tests in 49ms.
Running tests.
[+] <ScriptBlock>  103ms (21ms|36ms)
Tests completed in 108ms Tests Passed: 1,  Failed: 0,  Skipped: 0,  Inconclusive: 0,  NotRun: 0

Let me know if that helps clarify the motivation for changing the existing test. I think that's net a good change, but let me know if you think otherwise.

Thanks for the test, is this solving a real issue for you? I don't normally follow the success output, and I don't expect people to run tests from scriptblocks that much. I mostly added that to be able to test pester easily. Do you run tests from scriptblocks?

Before:

After:

I don't see any information lost from failed tests because there we show the failure directly, which is great.

Thanks for the test, is this solving a real issue for you?
I don't normally follow the success output, and I don't expect people to run tests from scriptblocks that much. I mostly added that to be able to test pester easily. Do you run tests from scriptblocks?

We give multiple other teams the ability to run Pester tests within another ES, and we support scriptblocks. In the past, when I've guessed there were Pester features other teams wouldn't be using, I've guessed wrong : )

I don't see any information lost from failed tests because there we show the failure directly, which is great.

For the failure case, the line with the failure is currently just "[-]", which doesn't identify the name of the file with the ScriptBlock that failed. Displaying that information consistently allows us to integrate it back into our ES's logs.

ok merged into pester 6, do you need those changes in pester 5?

Thanks, @nohwnd!
Yes, if we could get these fixes into Pester 5 as well, that would be great - thanks!

/backport to rel/5.x.x

Started backporting to rel/5.x.x: https://github.com/pester/Pester/actions/runs/14946881012