Nimblesite / Nimblesite/SharpLsp
Test Explorer: Debug Test never stops on a breakpoint — no user code is executed
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 132
- Forks
- 5
- Avg merge
- 6h 24m
- Merged PRs (30d)
- 27
Description
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 #232 for the on-disk evidence filterClauseescapes the parentheses, so--filtermatches 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
- Open
src/fixtures/real-world/fluentvalidation. - Put a breakpoint inside any
[Fact]inAbstractValidatorTester. - Press Debug Test.
- 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-coreclrattach actually completed (theSharpLsp Test Debugterminal + 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
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/editors/vscode/src/testing.ts at SharpLspTestController.debugTests, collectTests(request), and filterIdsFor(request, tests), then reproduce with the FluentValidation fixture and the reported [Fact]. Use VSTEST_HOST_DEBUG=1 plus the SharpLsp Test Debug terminal and extension log to confirm attach and breakpoint binding. Done means the selected test runs under the debugger, reaches the breakpoint, and reports an outcome.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, typescript
- Domain
- developer-experience, testing
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100