Set-Location $null run slowly and High CPU usage

[Andy-AO]

Describe 'root' {it 'test' {Set-Location $null}}

Run this script and wait for the execution to complete. Running this script again should also return the test results immediately, but the actual situation is that PowerShell will not be able to interact, and the CPU utilization begins to rise abnormally. Wait a few minutes before you can receive the return value, and may be accompanied by an error message.The same conclusion can be reached by testing in new virtual machines.

Get-ChildItem: C:\Users\Andy\Documents\PowerShell\Modules\Pester\5.3.0\Pester.psm1:3512
Line |
3512 |              & $SafeCommands['Get-ChildItem'] -Recurse -Path $p -Filte …
     |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Could not find a part of the path 'C:\Users\Andy\Documents\Tencent
     | Files\11681258\FileRecv'.

Pester version     : 5.3.0 C:\Users\Andy\Documents\PowerShell\Modules\Pester\5.3.0\Pester.psm1
PowerShell version : 7.1.3
OS version         : Microsoft Windows NT 10.0.18363.0

[fflaten]

Can reproduce, kinda... The problem isn't the code, it's the fact that you're invoking your test-file using a relative path and call this code.

Let's say that code is in a file called c:\temp\mydemo.tests.ps1 and you're in c:\temp. You invoke your test like Invoke-Pester mydemo.tests.ps1. When it calls Set-Location $null, your prompt is moved to $env:userprofile (C:\Users<username>). If you invoke Invoke-Pester mydemo.tests.ps1 again, then Invoke-Pester will not find the file in the current folder, but start recursively searching for it inside your PWD (userprofile). This is time-consuming and usually fails in access denied or something else at one point. If you use absolute paths like Invoke-Pester c:\temp\mydemo.tests.ps1 it will always work the same. Does that match you behavior?

I've seen this before, but wasn't sure if it was considered an issue or user-error, so never reported it myself. Can't remember seing a dedicated issue for it. Some ideas to solve it though:

• Consider limiting -Path in Invoke-Pester to not go down the rabbit hole (search recursively for filenames) by default
• Or maybe just add Push/Pop-Location so that a Pester run won't affect your session's PWD.

[Andy-AO]

@fflaten

I actually run it with an absolute path, not a relative path

In VSCode, press F5 to run this test file, there will be no Invoke-Pester, but run the absolute path directly, for example c:\temp\mydemo.tests.ps1, that's how I found this problem.

After your reminder, I switched to Invoke-Pester c:\temp\mydemo.tests.ps1 and the problem disappeared.

[Andy-AO]

@fflaten
Running any script in the user folder directly using the absolute path method (without Invoke-Pester) seems to cause this problem.

[Andy-AO]

This issue was resolved in VSCode by changing the key binding settings, but other users may still experience the issue by default. It is recommended to fix it anyway.

[fflaten]

Will look into the interactive execution logic when I get home. Running scripts directly calls Invoke-Pester internally. Maybe it just passes the filename and not path at that point. Will probably split into multiple issues. One for interactive execution and one for the fact that pester changes the terminal session PWD.

What changes to the keybinding did you do btw? Disable F5 to run script files completely?

[fflaten]

@fflaten
Running any script in the user folder directly using the absolute path method (without Invoke-Pester) seems to cause this problem.

Found the culprit for this scenario. I didn't completely remove a variable name in a previous PR which caused interactive execution (running files directly) to basically run Invoke-Pester -Path 'Path' causing the same slow recursive search. I've submitted a related PR as a bugfix for that specific scenario.

@nohwnd I didn't tag the PR as a fix for this issue as we might want to consider a more generic improvement, see my initial comment.

[nohwnd]

Yeah, we would probably capture the original path and CD back to it at the end, good idea.

[Andy-AO]

@fflaten The default command is workbench.action.debug.run or PowerShell.RunPesterTestsFromFile, but there is actually another command called PowerShell.RunPesterTestsFromFile, which is the command specifically for Pester test scripts, but it has no key bindings by default.

When both key bindings match, the key binding near the end of the JSON file has higher priority, so you just need to set the same hotkey and place it after the two items above.

Specifically, these two items ↓

{
        "key": "ctrl+f5",
        "command": "PowerShell.RunPesterTestsFromFile",
        "when": "resourceFilename =~ /.*Tests\\.ps1/"
    },
    {
        "key": "f5",
        "command": "PowerShell.DebugPesterTestsFromFile",
        "when": "resourceFilename =~ /.*Tests\\.ps1/"
    }