Exercise 3: What the Pester Test Verifies, and Why Mocking Is Right Here — Possible Solution
====================================================================

WHAT THE TEST IS ACTUALLY VERIFYING
------------------------------
The test verifies that Get-FleetHealthReport's own naming-pattern validation logic (Step 1) genuinely prevents a malformed computer name from ever reaching Get-CimInstance - it's testing the "reject bad input early" behavior specifically, not whether a real server can actually be queried successfully.

WHY MOCKING Get-CimInstance IS THE RIGHT APPROACH
------------------------------
Per Chapter 10, Mock replaces a real cmdlet's behavior for the duration of a test, isolating the function under test from its real dependencies. Running this specific test against a real server would require an actual reachable machine to exist, be network-accessible, and be correctly configured for CIM/WinRM every time the test suite runs - none of which has anything to do with what this particular test is actually trying to confirm (that validation happens before any query attempt). By mocking Get-CimInstance and asserting Should -Invoke Get-CimInstance -Times 0, the test directly and reliably confirms the validation logic works, without depending on any real infrastructure being available, and without the test's outcome ever being affected by an unrelated network or server problem.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that the test is checking the early-validation behavior specifically, and correctly explains why mocking isolates that specific logic from real infrastructure dependencies, keeping the test reliable and focused on the actual behavior being verified.