Nimblesite / Nimblesite/SharpLsp

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

Open
#233 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug critical
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.debugTestscollectTests(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
  • 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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.