Files
PowerShell-PowerShell/test/powershell/Modules/Microsoft.PowerShell.Utility/Enable-RunspaceDebug.Tests.ps1
T
Tyler James Leonhardt 13fd3af810 New New-PSBreakpoint cmdlet & new -Breakpoint parameter for Debug-Runspace (#8923)
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`
2019-04-13 19:14:53 -07:00

78 lines
2.4 KiB
PowerShell

# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License.
$FeatureEnabled = $EnabledExperimentalFeatures.Contains('Microsoft.PowerShell.Utility.PSDebugRunspaceWithBreakpoints')
Describe "`Enable-RunspaceDebug -Breakpoint` Unit Tests - Feature-Enabled" -Tags "CI" {
BeforeAll {
if (!$FeatureEnabled) {
Write-Verbose "Test Suite Skipped. The test suite requires the experimental feature 'Microsoft.PowerShell.Utility.PSDebugRunspaceWithBreakpoints' to be enabled." -Verbose
$originalDefaultParameterValues = $PSDefaultParameterValues.Clone()
$PSDefaultParameterValues["it:skip"] = $true
return
}
#Set up script file 1
$scriptFileName1 = Join-Path $TestDrive -ChildPath breakpointTestScript.ps1
$contents = @"
function Hello
{
`$greeting = 'Hello, world!'
write-host `$greeting
}
function Goodbye
{
`$message = 'Good bye, cruel world!'
write-host `$message
}
Hello
Goodbye
"@
$contents > $scriptFileName1
# The breakpoints are created here because when the tests are run with the experimental feature off,
# this command does not exist and the Pester tests fail to work
$breakpointArr = @(
New-PSBreakpoint -Line 12 $scriptFileName1
New-PSBreakpoint -Line 13 $scriptFileName1
)
$iss = [initialsessionstate]::CreateDefault2();
$testRunspace1 = [runspacefactory]::CreateRunspace($iss)
$testRunspace1.Name = "TestRunspaceDebuggerReset"
$testRunspace1.Open()
}
AfterAll {
if (!$FeatureEnabled) {
$global:PSDefaultParameterValues = $originalDefaultParameterValues
return
}
# Clean up
$testRunspace1.Dispose()
}
It "Can set breakpoints in the runspace - <Name>" -TestCases @(
@{
Name = "Current runspace"
Runspace = [System.Management.Automation.Runspaces.Runspace]::DefaultRunspace
Breakpoints = $breakpointArr
},
@{
Name = $testRunspace1.Name
Runspace = $testRunspace1
Breakpoints = $breakpointArr
}
) {
param($Runspace, $Breakpoints)
Enable-RunspaceDebug -Breakpoint $Breakpoints -Runspace $Runspace
$Runspace.Debugger.GetBreakpoints() | Should -Be @($Breakpoints)
}
}