Update Pester to 6.0.0

[nohwnd]

Pester 6.0.0 is now released 🎉 — thanks for letting me pilot the release candidates against your suite.

This updates the earlier release-candidate pin to the final 6.0.0 and keeps the test changes needed to run on Pester 6 (already in this PR). It's the same migration you'd make yourself, so you're welcome to merge it, cherry-pick just the compatibility changes, or use it purely as a reference.

The Pester suite (AppVeyor + S3 integration + build) passes on 6.0.0. The only unrelated red seen during the pilot was Install-DbaInstance failing on WinRM ("server name cannot be resolved") — a remote-host/infra limitation on a fork, not Pester.

The real-world CI signal from this pilot was genuinely valuable in getting 6.0.0 right. Thanks for the CI time this used, and for maintaining a suite I could test against.

This PR was co-authored by GitHub Copilot.

— Jakub & Copilot

[niphlod]

ty @nohwnd . let's wait and see.

[nohwnd]

@niphlod something failed, can you please help me decipher it? Or re-run if that is known flakiness in this pipeline run.

[niphlod]

re-started, it's seemingly a "flaky" occurence, but let's wait and see.

[niphlod]

not so flaky, so calling the big guns here... @andreasjordan , any tips/pointers ?

[andreasjordan]

I'm currently on vacation. I can try to run all tests in my lab in about two weeks.

[niphlod]

first failure is with some obscure message at the test here https://github.com/nohwnd/dbatools/blob/15c3981b4031b56719ff49c647bf47eb82aad83e/tests/Install-DbaInstance.Tests.ps1#L351 .

Path           : Install-DbaInstance/Negative tests/fails when update execution has failed
Name           : It fails when update execution has failed
Result         : Failed
Message        : ErrorRecord: Expected an exception with message like '*Installation failed with exit code 12345*' to be thrown, but the message was 'Connecting to remote server HOST failed with the following error message : The 
                 WinRM client cannot process the request because the server name cannot be resolved. For more information, see the about_Remote_Troubleshooting Help topic.'. from 

tries to use winrm but this test is riddled with mocks, so it seems mocks aren't "engaged"

[andreasjordan]

Not all tests are running because of our PR-filtering for changed files. Can we trigger a complete run?

[niphlod]

at the very end, sure, it'll be beneficial. For the time being, let's at least wait for specific changed tests to pass

[nohwnd]

@niphlod can you possibly add me as contributor? So I don't require approval on the build tasks. Will touch just this PR, need to bisect it but don't have the setup to run it locally.

[nohwnd]

Thanks for digging into this, @niphlod 🙏 — and no rush, @andreasjordan, enjoy the vacation. I bisected the Install-DbaInstance failure; here's what's going on, since the same mechanism probably explains a few of the other files too.

Root cause: an intended Pester 6 change

Pester 6 removed "mock fall-through" (pester/Pester#2654, fixing pester/Pester#2178). Before, a Mock with a -ParameterFilter that didn't match a call would silently fall through and run the real command. In Pester 6 that now throws:

No mock for command '…' matched the call: none of the parameter filters matched, and there is no default mock to fall back to.

It's deliberate — the silent fall-through hid real bugs — but it means any test that mocks a command only for specific arguments (expecting the real command for the rest) now needs an explicit default mock. I've kept the Pester-side notes in pester/Pester#2829.

Why Install-DbaInstance.Tests.ps1 fails (the odd message at L351)

The file's only parameter-filtered mock is for Win32_processor:

Mock Get-DbaCmObject -ModuleName dbatools -MockWith { ... } -ParameterFilter { $ClassName -eq "Win32_processor" }

But the code path also calls Get-DbaCmObject -ClassName win32_ComputerSystem inside Resolve-DbaNetworkName (~L259). Under Pester 5 that fell through to real CIM; under Pester 6 it throws. Resolve-DbaNetworkName swallows the error in its outer catch (~L282), so ComputerName keeps the earlier reverse-DNS value. On AppVeyor that's a non-local name → IsLocalHost is $false → Invoke-DbaAdvancedInstall takes the remote branch (New-PSSession) → the WinRM "Connecting to remote server" errors and ~139s timeouts, instead of the expected Installation failed with exit code 12345. That's also why it only shows up on AppVeyor — locally the reverse-DNS name is the local machine, so the wrong branch is never taken.

Suggested fix (same approach Update-DbaInstance.Tests.ps1 already uses)

Mock the resolver so the tests stay offline and deterministic:

Mock -CommandName Resolve-DbaNetworkName -ModuleName dbatools -MockWith {
    [PSCustomObject]@{
        ComputerName     = $env:COMPUTERNAME
        FullComputerName = $env:COMPUTERNAME
    }
}

This removes the unmocked win32_ComputerSystem call and keeps IsLocalHost true. (Equivalent alternatives: a second Get-DbaCmObject mock for win32_ComputerSystem, or a catch-all default mock.)

I couldn't fully validate it on my side — the file needs a Windows host to get past Write-IniFile, and the failure only reproduces with AppVeyor's non-local reverse-DNS — so it'd be great to confirm on a build.

Likely the same story elsewhere

Any test that mocks a command with -ParameterFilter but also reaches it with other arguments will hit this. -ParameterFilter shows up in ~24 files; the ones that filter Get-DbaCmObject the same way as here are Invoke-DbaAdvancedInstall.Tests.ps1 and Get-DbaService.Tests.ps1 — probably worth a look. A quick grep for -ParameterFilter and adding a default mock (or broadening the filter) where the command is also called with non-matching args should get ahead of most of them.

Happy to push the Install-DbaInstance change if useful. And @niphlod, if the contributor offer still stands I'd gladly take it so I can iterate on the build directly. Thanks again!

[potatoqualitee]

@nohwnd we've invited you to the repo, happy to have you here 😊

[nohwnd]

Thanks, accepted. Have repro already, so at least I can take it to green.

[nohwnd]

Pushed it as a3054ec — AppVeyor is green now ✅ (build 2.1.32102).

Install-DbaInstance.Tests.ps1 passes in the scenario=default job that was the lone failure before, and the whole matrix (SINGLE ×3, MULTI, COPY, HADR, RESTART, default) is green. That confirms the diagnosis: the single Mock Resolve-DbaNetworkName -ModuleName dbatools keeps IsLocalHost true, so the code never takes the remote/WinRM branch — no more "server name cannot be resolved".

The other -ParameterFilter files I flagged above (Invoke-DbaAdvancedInstall, Get-DbaService, …) are still worth a scan for the same pattern, but this unblocks the Install-DbaInstance failure. Thanks for the repo invite, @potatoqualitee 🙏