Test Explorer: Debug Test never stops on a breakpoint — no user code is executed

[MelbourneDeveloper]

Summary

Set a breakpoint in a test, press Debug Test (the CodeLens above the method, or the Debug profile in the Testing view) against FluentValidation, and nothing happens: no stop, no hit breakpoint, no reported outcome. The run ends without the debuggee ever reaching user code.

Reported against FluentValidation.Tests.AbstractValidatorTester.When_the_Validators_pass_then_the_validatorRunner_should_return_true, breakpoint on the validator.RuleFor(...) line.

Almost certainly the same root cause as #232

A debug run reuses the ordinary run's selection and filter:

• SharpLspTestController.debugTests → collectTests(request) → filterIdsFor(request, tests) (src/editors/vscode/src/testing.ts:506-529)
• those ids are the discovered test ids, which on this project carry xUnit's unique-ID suffix — …When_the_Validators_pass_then_the_validatorRunner_should_return_true (2bd9e5a56e8ea7c7114cb93b1c19bd50a55b7bf4) — see Test Explorer: every run reports "No result reported" — discovered ids carry xUnit's unique-ID suffix #232 for the on-disk evidence
• filterClause escapes the parentheses, so --filter matches no test

Under VSTEST_HOST_DEBUG=1 the test host still announces its pid and waits, so SharpLsp attaches as designed ([DEBUG-FEATURES-TESTS]) — and then the host runs zero tests and exits. From the user's side that is indistinguishable from "the debugger did nothing": the breakpoint is never reached because the test never runs.

Reproduction

1. Open src/fixtures/real-world/fluentvalidation.
2. Put a breakpoint inside any [Fact] in AbstractValidatorTester.
3. Press Debug Test.
4. No stop; the session ends with no outcome reported.

Expected

The test host runs the selected test under the attached debugger and stops on the user's breakpoint.

What still needs confirming

This issue is filed on the user-reported symptom plus the traced filter defect. Not yet verified from a captured session:

• whether the sharplsp-coreclr attach actually completed (the SharpLsp Test Debug terminal + extension log would say), or whether the attach itself refused
• whether the breakpoint bound (verified) before the host exited

If #232 is fixed and Debug Test still does nothing, this issue stays open on its own merits — so it is tracked separately rather than folded into #232.

Environment

• Windows 11, .NET SDK 10.0.303
• SharpLsp branch fixloading
• FluentValidation.Tests: <TargetFrameworks>net8.0;net9.0</TargetFrameworks>, xunit 2.2.0, xunit.runner.visualstudio 2.2.0

[MelbourneDeveloper]

#232 is now fixed on fixloading, and with it the mechanism this issue was traced to: the ids the Debug profile builds its --filter from are no longer decorated with the adapter's unique ID, so the selected test can actually match and run under the attached host.

That is not yet a confirmation that Debug Test works on this project — it removes the one defect that provably made it impossible. Still unverified:

• whether the sharplsp-coreclr attach completes against a legacy-adapter project
• whether the breakpoint binds (verified) before the host runs the test

Worth a retry on FluentValidation once #232 lands. If the breakpoint still does not hit, the SharpLsp Test Debug terminal output and the extension log from that attempt are what this issue needs next — the current report has no captured session behind it.

Keeping this open until someone confirms a real stop on a real breakpoint.