This PR implements a new MSTest feature that allows developers to automatically launch a debugger when test assertions fail. This is particularly useful for debugging intermittent or hard-to-reproduce test failures by preserving the exact program state at the moment of failure.

Implementation

The feature is controlled via MSTest configuration and has zero performance impact when disabled:

XML Configuration (runsettings):

<RunSettings>
  <MSTestV2>
    <LaunchDebuggerOnFailure>true</LaunchDebuggerOnFailure>
    <DebuggerLaunch_TestFilter>MyFlakyTest</DebuggerLaunch_TestFilter>
  </MSTestV2>
</RunSettings>

JSON Configuration (testconfig.json):

{
  "mstest": {
    "execution": {
      "launchDebuggerOnFailure": true,
      "debuggerLaunchTestFilter": "MyFlakyTest"
    }
  }
}

Environment Variable Fallback:

# Enable debugger launch on any test failure
export MSTEST_LAUNCH_DEBUGGER_ON_FAILURE=1
dotnet test

# Optional: Only launch debugger for specific tests
export MSTEST_LAUNCH_DEBUGGER_TEST_FILTER="MyFlakyTest"

Key Changes

• Enhanced MSTestSettings: Added LaunchDebuggerOnFailure and DebuggerLaunchTestFilter properties with XML and JSON parsing support
• Configuration Integration: Settings are processed through the standard MSTest configuration pipeline and applied to the TestFramework layer
• Minimal Implementation: Clean separation between adapter configuration and TestFramework execution
• Comprehensive Tests: Updated unit tests to validate the new MSTestSettings-based approach

Benefits

• ✅ Preserves Stack State: Debugger attaches at exact assertion failure point
• ✅ Universal Compatibility: Works with Visual Studio, VS Code, and console debugging
• ✅ Zero Performance Impact: No overhead when feature is disabled
• ✅ Standard Configuration: Uses existing MSTest configuration patterns (runsettings/testconfig)
• ✅ Targeted Debugging: Optional test name filtering for specific scenarios
• ✅ Non-Breaking: Fully backward compatible with existing test suites and environment variable configuration

Usage Example

[TestMethod]
public void FlakyIntegrationTest()
{
    var service = new MyService();
    var result = service.ProcessData(complexInput);
    
    // If this fails with debugger enabled, you can inspect:
    // - service state, complexInput values, result contents
    // - Full call stack and thread context
    Assert.AreEqual(expectedValue, result.Value);
}

This addresses the core requirements from the issue:

• Automatic debugger launch on test failure ✅
• Configurable via MSTest settings (not default behavior) ✅
• Works for both VS and console scenarios ✅
• Preserves interesting stack state as requested ✅
• Supports filtering options for targeted debugging ✅

Fixes #2033.

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.