Replay Debugger: Debug Tests

[ntotten]

In order to more easily use the replay debugger we will expose an option to “Debug Tests” in addition to the current “Run Tests” options.

UX

The user starts on a test class opened in VS Code. They would set breakpoints of where they want to debug.

Today, on each test class we show the codelens Run All Tests and on test methods we show the option Run Test. This feature will change these codelens to provide two options in each case instead of one.

This would change the codelenes to the following.

@isTest
Run All Tests | Debug All Tests
public class MyTest { 

  Run Test | Debug Test
  static testMethod void foo() {
  }
  
}

When a user clicks either Debug All Tests or Debug Test. The Following happens:

1. Debug Logging is enabled
2. The test(s) are run
3. The debug log associated with the test run is downloaded
4. Replay debugger is started using the previously downloaded log

Note, we should skip the step where the debug log is shown and jump immediately to debugging the code. The debug log should never be shown when using this feature.

Warning: Breakpoints/Checkpoints
If a user clicks Debug All Tests or Debug Test and doesn't have a breakpoint or checkpoint set, we should show a confirmation dialog.

Message Text:
You are about to debug tests, but don't have any breakpoints or checkpoints set. You should set some before running this command.

Buttons:

• Continue → proceeds to running and debugging the tests
• Cancel → cancels the command, allowing the user to go back and set breakpoints

Configuration Option: Interactive Debugger
Because some users have purchased interactive debugger licenses, we should set a preference to use the interactive debugger when running tests instead of the replay debugger. The functionality would be the same, except it would happen in real-time.

Test Panel
The debug test(s) options should also be invokable from the test panel. Functionality is the same.

[ralphcallaway]

this is a wonderful approach, very excited that this is potentially being prioritized, would greatly improved developer ergonomics :)

[ralphcallaway]

this same approach would extend very well to the "Execute Anonymous Apex With Editor Contents" command

regarding the breakpoints warning, if none have been set you might consider just having the debugger stop on the first line. it's a use case I often use. although less much less frequently then run to first breakpoint, so your proposed behavior of continuing to the first breakpoint if one is set makes a lot of sense. that said, does seem tricky to figure out if a breakpoint is in the code path or not ... if it's not that could be pretty confusing UX in that everything would run launch do a lot of work and then just be done

[sc5148]

When is the planned release for this?

[smaddox-sf]

This has been delivered