Tyler James Leonhardt
13fd3af810
This PR does 4 things: * Adds a new cmdlet `New-PSBreakpoint` which creates new `Breakpoint` objects and writes them to the pipeline * Adds a `-Breakpoint` parameter to `Debug-Runspace` which will receive `Breakpoint` objects * Makes the constructors for `*Breakpoint` public for use with the API * Makes `Debugger.GetBreakpoint(string id)` and `Debugger.GetBreakpoints()` public since `SetBreakpoints` is public Note: `New-PSBreakpoint` and `Set-PSBreakpoint` (which already exists) are similar... but `Set-PSBreakpoint` also sets the breakpoints in the _current_ runspace. This is not ideal if we want to set breakpoints in a _different runspace than the current one_. ## PR Context The "Attach to process" debugging experience in the PowerShell extension for VSCode is _ok_ but it's not great. The reason it's not great is due to the `BreakAll` feature of PowerShell debugging which, when you run `Debug-Runspace`, will break at the first piece of code that gets run. This is not ideal when you "Attach to process" _and then_ run your code in the other runspace. Today, the experience drops you in `PSReadLine`'s psm1 if PSRL is available or in the vscode PowerShell helper psm1. It's unexpected for the user and not ideal. This PR will allow the extension to pass in the breakpoints that need to be set initially with `BreakAll` turned off for none of this silly behavior. ### Silly behavior example If you want a repro, try this: PowerShell instance 1: ``` Enter-PSHostProcess -Id $otherprocesspid Debug-Runspace 1 ``` PowerShell instance 2: ``` ./runfoo.ps1 ``` Note that you end up NOT `runfoo.ps1`
Pester Testing Test Guide
Also see the Writing Pester Tests document.
Running Pester Tests
Go to the top level of the PowerShell repository and run: Start-PSPester
inside a self-hosted copy of PowerShell.
You can use Start-PSPester -Tests SomeTestSuite* to limit the tests run.
Testing new powershell processes
Any launch of a new powershell process must include -noprofile so that
modified user and system profiles do not causes tests to fail. You also must
take care to call the development copy of PowerShell, which is not the first
one on the path.
Example:
$powershell = Join-Path -Path $PsHome -ChildPath "pwsh"
& $powershell -noprofile -command "ExampleCommand" | Should Be "ExampleOutput"
Portability
Some tests simply must be tied to certain platforms. Use Pester's
-Skip directive on an It statement to do this. For instance to run
the test only on Windows:
It "Should do something on Windows" -Skip:($IsLinux -Or $IsMacOS) { ... }
Or only on Linux and OS X:
It "Should do something on Linux" -Skip:$IsWindows { ... }
Pending
When writing a test that should pass, but does not, please do not skip or delete
the test, but use It "Should Pass" -Pending to mark the test as pending, and
file an issue on GitHub.