fix(engine): apply --treenode-filter to --list-tests

[thomhurst]

Problem

--list-tests ignored --treenode-filter and listed every test in the assembly. Users expect app --list-tests --treenode-filter X to list only the tests filter X selects — the same set a real run would execute.

Root cause

MTP routes --list-tests to a DiscoverTestExecutionRequest, which flows through TestDiscoveryService.DiscoverTests with isForExecution: false. The filter was applied only when isForExecution was true:

varfilteredTests=isForExecution?_testFilterService.FilterTests(filter,allTests):allTests;

isForExecution legitimately gates side-effecting work — argument registration / fixture creation (#6151) and dependency-closure expansion. But filtering itself is pure (MatchesTest only compares the test's path/properties against the filter), so running it during discovery was always safe; it just was never wired up. Filtering got conflated with the side-effect gate.

Fix

Apply the filter during discovery too, but only when a real filter is present:

varhasRealFilter=filteris not (null or NopFilter);varfilteredTests=(isForExecution||hasRealFilter)?_testFilterService.FilterTests(filter,allTests):allTests;

• No filter (bare --list-tests, IDE Test Explorer) → null/NopFilter → returns all tests unchanged, including [Explicit] ones (which FilterTests would otherwise strip). No behavior change.
• Filter present → reuse FilterTests, so the listing mirrors exactly what a run with that filter would execute.
• No fixture leaks — RegisterTestsAsync is still called with isForExecution: false, so RegisterTestArgumentsAsync stays skipped.
• No dependency pull-in — the dependency-closure block stays guarded by isForExecution.

Engine-runtime only; works identically in reflection and source-generated modes since both flow through TestDiscoveryService. No snapshot/source-gen output changes.

Tests

Adds ListTestsFilterTests (reflection + source-generated modes):

• filter lists only matching tests,
• bare --list-tests still lists everything (guards the no-filter path).

Manually verified against TUnit.TestProject:

Check	Result
source-gen + [Category=Pass] filter	only Pass*, 0 Fail*
reflection + filter	86 Pass / 0 Fail
no filter	full 18,138 listed, Pass1+Fail1 present
new engine test (4 cases)	all pass

[codacy-production]

Up to standards ✅

🟢 Issues0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics7 complexity

Metric	Results
Complexity	7

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

Summary: The fix correctly widens filtering in TestDiscoveryService.DiscoverTests to also apply during discovery-only requests (isForExecution: false) when a real filter (filter is not (null or NopFilter)) is present, while leaving bare --list-tests/IDE Test Explorer discovery (null/NopFilter) and side-effecting work (RegisterTestsAsync, dependency-closure expansion) unchanged. Verified:

• Filtering via TestFilterService.FilterTests is side-effect-free, so applying it outside the isForExecution gate is safe.
• The new ListTestsFilterTests.cs exercises both reflection and source-generated modes (Dual-Mode compliance) and follows the established InvokableTestBase/ExternalCancellationTests conventions for driving the built test executable, with a documented reason for not reusing InvokableTestBase directly.
• No source-generator output or public API changes, so no snapshot updates were needed.
• The intentional tradeoff (dependency-closure expansion stays gated on isForExecution, so listing with a filter won't show pulled-in dependency tests that a real run would execute) is clearly documented in the PR description.

🤖 Generated with Claude Code